Swift has grown up since 2014 and taken up new primary use cases. This homepage refresh recenters across those, which for non-Apple cases makes this a much better starting point for understanding the goals and current state of the language, what you can use it for and how.
I don’t know and I really love the language. Swift on the server for instance never really took off.
Kotlin seems to be going much harder at becoming the LLVM cross-platform language for everything. That’s something that should have been Swift’s by all rights but Apple’s infinite resources could not be marshalled behind that strategy.
That led me to conclude a while back that Swift will be knee-capped to be limited to Apple’s backwater and can never be more than that. I got out and never looked back.
I can’t say whether it’s ever going to arrive as a popular server-side tool, but I still think it’s nascent rather than failed. They’re playing a long game. The kinds of capabilities that have long been intended to lead Swift to other use cases have only just begun to be available. Concurrency features are only a couple years old, ownership has been planned for ages and its Noncopyable types are brand new, Linux support exists but is not any kind of slam dunk yet, and embedded Swift is a just-last-week thing.
I think the technical obstacles are slowly falling, but there is another big one that may not budge—Apple has (earned) a PR problem in the Linux world, which I have to think interferes with development of enthusiast communities that don’t come from development on their platforms, like you probably guessed I do.
I mean Swift can happily remain nascent while Kotlin rapidly becomes the standard language to develop JVM server side applications with Spring/Boot.
My fundamental guess is that Apple needs to have its own language that they control from a purely legal/strategic perspective. That language is Swift, a language that Apple fully controls. To maintain that control it’s actually better if Swift does not become hugely popular. Being used on only iOS devices is more than popular enough for their purposes.
Why would I want to use swift over any of the other strict mutable functional languages out there? It sounds completely fine but non-unique (assuming I don’t care about Apple apis).
Actor model concurrency, data race detection, ARC instead of a GC thread, stable ABI, lots of safety without going whole hog on linear types like Rust, an async/await pattern the community is happy with, easy to pick up, good at data modeling, value and reference types without your having to be responsible for every step of each like C++, not that big of a non-Apple scene which could be a plus if you wanted to become a significant contributor. Negatives include the compile times not being that fast, much online help being specific to iOS, Linux support being stable but not as fleshed out, and having to justify your choices online ;) . Not all Apple APIs are specific to Apple SDKs and platforms, some are just packages.
Swift has grown up since 2014 and taken up new primary use cases. This homepage refresh recenters across those, which for non-Apple cases makes this a much better starting point for understanding the goals and current state of the language, what you can use it for and how.
I don’t know and I really love the language. Swift on the server for instance never really took off.
Kotlin seems to be going much harder at becoming the LLVM cross-platform language for everything. That’s something that should have been Swift’s by all rights but Apple’s infinite resources could not be marshalled behind that strategy.
That led me to conclude a while back that Swift will be knee-capped to be limited to Apple’s backwater and can never be more than that. I got out and never looked back.
I can’t say whether it’s ever going to arrive as a popular server-side tool, but I still think it’s nascent rather than failed. They’re playing a long game. The kinds of capabilities that have long been intended to lead Swift to other use cases have only just begun to be available. Concurrency features are only a couple years old, ownership has been planned for ages and its Noncopyable types are brand new, Linux support exists but is not any kind of slam dunk yet, and embedded Swift is a just-last-week thing.
I think the technical obstacles are slowly falling, but there is another big one that may not budge—Apple has (earned) a PR problem in the Linux world, which I have to think interferes with development of enthusiast communities that don’t come from development on their platforms, like you probably guessed I do.
I mean Swift can happily remain nascent while Kotlin rapidly becomes the standard language to develop JVM server side applications with Spring/Boot.
My fundamental guess is that Apple needs to have its own language that they control from a purely legal/strategic perspective. That language is Swift, a language that Apple fully controls. To maintain that control it’s actually better if Swift does not become hugely popular. Being used on only iOS devices is more than popular enough for their purposes.
Why would I want to use swift over any of the other strict mutable functional languages out there? It sounds completely fine but non-unique (assuming I don’t care about Apple apis).
Actor model concurrency, data race detection, ARC instead of a GC thread, stable ABI, lots of safety without going whole hog on linear types like Rust, an async/await pattern the community is happy with, easy to pick up, good at data modeling, value and reference types without your having to be responsible for every step of each like C++, not that big of a non-Apple scene which could be a plus if you wanted to become a significant contributor. Negatives include the compile times not being that fast, much online help being specific to iOS, Linux support being stable but not as fleshed out, and having to justify your choices online ;) . Not all Apple APIs are specific to Apple SDKs and platforms, some are just packages.
Even on macOS, it’s annoying. For things common on Apple platforms, most of the results for i.e. SwiftUI are going to be iOS focused or specific.