Holy hreck. Here I am still wondering whether it's fair to call myself an "experienced" programmer, and it's been ten years since the original announcement of Swift, a language I've been using since.

It's hard to pick a favourite when languages are so different in their personality and purposes, but my reaction is that Swift would win if I did the math.

Which of its virtues has time proven valuable, looking back? A good handful, none of which I've known from other languages yet.

The process of writing Swift is tightly coupled with the compiler. A typical programming workflow is to write the program, run the program, encounter errors or crashes, and go back to fix things. Swift is designed for protection from errors and crashes at the syntactic level. Crashes can still happen, but much more often, errors that in other languages might result in crashes are simply invalid Swift, so the compiler will point them out before you run anything.

Swift is also particularly customizable. Where in other languages you might not aesthetically care for the name of a type, or the textual pattern by which you might have to leverage some feature, Swift often allows for some way to customize it, giving you a sort of language-level way to design the language itself.

Its foundations also seem closer to the pure abstract than those of other languages. For example, some languages have primitive types like "Int" and "Float" for whole and fractional numbers. But I believe in Swift, those types are built on even more primitive types, so the passionate could theoretically make their own first-class number types. Even the operators, like the plus, minus or "greater than" signs, are themselves implemented on still lower-level protocols, and implementation of your own operators is similarly possible. You have to dig surprisingly deep to find a token in Swift that's truly "reserved" by the language.

Speaking in terms of principle, design guidance for interfaces emphasizes "clarity at the point of use." That means that when a programmer uses Swift, it should be intuitive to use a function just by reading it. For elaboration when needed, inline documentation is supported as well. The more complex features of Swift, which have evolved over this decade, exist largely in service of the ability to write interfaces that are that clear and easy to use. The more advanced you want to get, the deeper you can dig, but you shouldn't have to dig deep just to get something working. It's a testament to the thinking behind Swift that it's evolved to include many modern features without losing that approachability.

The people at Apple initiated Swift and now use it for most of their projects, but only a year or two in, it became one of their main open source projects, with its own dedicated site, guides, and community forums. It's cited as used on servers (I haven't tried this, but I suspect that's a joy compared to some alternatives), and for cross-platform command-line tools. It is described as a "general-purpose" language, good for the high-level stuff needed by large modern apps, as well as the bit-juggling wizardry traditionally left to the likes of C and friends.

Current weaknesses and areas for improvement?

Since it has been open source for so long, I wish it were known to be used for a wider range of things. I'd be truly intrigued if it could be somehow compiled into JavaScript for use on the Web, for example – not just on the server. But there must be other potential uses too.

Halfway between then and now, Apple built "SwiftUI," their own modern app framework for its own platforms, on top of its cumulative features. On its face, it's remarkably impressive, appearing to replace 20 years of varyingly complex APIs and graphical tools with the ability almost to type a line-by-line, more human-readable-than-ever description of an app and its functionality into existence. This ambitious effort has moved gracefully from infancy to adolescence, awaiting full maturity. The compiler, the aforementioned triumph of plain Swift, still hasn't caught up to SwiftUI's heavy dependence on things like chained functions and result builders. No doubt whatsoever they're working on it, and in the meantime, it's still difficult to imagine an easier experience writing platform-native apps.

It's heartening to look back and note that I've actually been on something of a journey with the evolution of this thing, and that I can speak with a little first-hand experience.