around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
https://github.com/swiftlang/swift/blob/main/CHANGELOG.md
Here are the evolution proposals that landed in 6.3: https://www.swift.org/swift-evolution/#?search=6.3
Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds.SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.
Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.
Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.
Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...
So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.
All for the love of it?
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
Swift Caching Compiler - https://github.com/jrz/tools
but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
Im curious how is this used?
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
It's a shame but it for sure needs BigTech for it to be used anywhere else.
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.