I don’t think Swift is ever going to be a real competitor as an app language on non-Apple platforms, given those platforms all have well-developed existing ecosystems for applications (.NET, Java/Kotlin, etc).
(But I don’t know what I don’t know. I’m talking as almost a complete outsider here.)
That leaves Swift as a really nice systems/server language in the same spaces as Go or Rust (which I realize have overlapping but very different spaces; I put Swift somewhere between the two on that continuum).
I’d really like to use Swift as a systems language on Linux but it just doesn’t seem ready for prime time there. The biggest problem for me is the lack of C interop the other way: using C from Swift is trivial, but using a Swift library from C is not officially supported.
(Go suffers from this problem too, but in a different way.)
Writing a “universal” library (callable from other languages easily) basically requires that it be written in C, C++, or Rust. Zig has good support for this, but the language is pre-1.0. D I think can do it but it seems moribund (correct me if I’m wrong).
Anyway, long story short, I want to see Swift as a viable competitor to Rust in the stdlib range of Rust’s use cases, but I don’t think it’s gonna happen. I just think that would be a place where Swift could thrive.
I asked a question here on lobste.rs a few weeks ago to see if anyone was using Swift on Linux, and all but one of the answers, sadly, was no. I would love to hear of people using Swift on Linux.)
I think that’s a fair treatment. As I understand it, server work is the current expansion goal, and (waves hands) all this concurrency work is on that critical path. Systems programming features, like a memory ownership model, come later. It remains primarily an application-level language and there’s a long way to go. I’m optimistic, but it will take time.
Definitely. I am excited about Actor proposal accepted and maybe implement process-based executor and supervisors for Actor. That would be very interesting!
Even if you’re interested and want to try to use it on anything other than a mac, it ends up being far from trivial. Apple apparently do internal CI builds on one release of Ubuntu so it basically works on Linux. But you’re not going to find packages; building from source is non-trivial and if you’re on something slightly unusual you can forget it.
At first glance, the language seems to have syntax rather like Rust and some nice features. But it seems every feature they ever considered got included. It was in production use early so had no period where things that didn’t work could be thrown out again. With Rust by contrast, there’s not much left of the language as it was when I first read up about it and played with it because lots of things got thrown out again. It’s reached a stable basis now but didn’t for some time.
I’d temper that a little; Swift has thrown out some features like currying syntax and basically renamed all functions in 3.0. The early years saw a lot of churn on the way to source and binary stability. And before that there were years of development before Apple announced the project at all. (I would guess that Rust was public very early in life.) The additions for SwiftUI go overboard if you ask some of us, but that’s all version 5.
I’d say Swift is maturing on Apple platforms but is barely past experimental elsewhere. Its feature set probably looks broad for how incompletely deployed it is.
Really glad to see the focus on performance improvements in the compiler & type system:
Runtime Performance and Code Size Improvements
In Swift 5.4, protocol conformance checks at runtime are significantly faster, thanks to a faster hash table implementation for caching previous lookup results. In particular, this speeds up common runtime as? and as! casting operations.
Further, consecutive array modifications now avoid redundant uniqueness checks.
Finally, there are a variety of performance improvements:
String interpolations are more aggressively constant-folded
Fewer retain/release calls, especially for inout function arguments and within loops
Generic metadata in the Standard Library is now specialized at compile time, reducing dirty memory usage and improving performance
I don’t think Swift is ever going to be a real competitor as an app language on non-Apple platforms, given those platforms all have well-developed existing ecosystems for applications (.NET, Java/Kotlin, etc).
(But I don’t know what I don’t know. I’m talking as almost a complete outsider here.)
That leaves Swift as a really nice systems/server language in the same spaces as Go or Rust (which I realize have overlapping but very different spaces; I put Swift somewhere between the two on that continuum).
I’d really like to use Swift as a systems language on Linux but it just doesn’t seem ready for prime time there. The biggest problem for me is the lack of C interop the other way: using C from Swift is trivial, but using a Swift library from C is not officially supported.
(Go suffers from this problem too, but in a different way.)
Writing a “universal” library (callable from other languages easily) basically requires that it be written in C, C++, or Rust. Zig has good support for this, but the language is pre-1.0. D I think can do it but it seems moribund (correct me if I’m wrong).
Anyway, long story short, I want to see Swift as a viable competitor to Rust in the stdlib range of Rust’s use cases, but I don’t think it’s gonna happen. I just think that would be a place where Swift could thrive.
I asked a question here on lobste.rs a few weeks ago to see if anyone was using Swift on Linux, and all but one of the answers, sadly, was no. I would love to hear of people using Swift on Linux.)
I think that’s a fair treatment. As I understand it, server work is the current expansion goal, and (waves hands) all this concurrency work is on that critical path. Systems programming features, like a memory ownership model, come later. It remains primarily an application-level language and there’s a long way to go. I’m optimistic, but it will take time.
Definitely. I am excited about Actor proposal accepted and maybe implement process-based executor and supervisors for Actor. That would be very interesting!
To be honest, I think it’s equally likely that Java will make a break-through in the Go/Rust space as Swift being successful there.
Even if you’re interested and want to try to use it on anything other than a mac, it ends up being far from trivial. Apple apparently do internal CI builds on one release of Ubuntu so it basically works on Linux. But you’re not going to find packages; building from source is non-trivial and if you’re on something slightly unusual you can forget it.
At first glance, the language seems to have syntax rather like Rust and some nice features. But it seems every feature they ever considered got included. It was in production use early so had no period where things that didn’t work could be thrown out again. With Rust by contrast, there’s not much left of the language as it was when I first read up about it and played with it because lots of things got thrown out again. It’s reached a stable basis now but didn’t for some time.
I’d temper that a little; Swift has thrown out some features like currying syntax and basically renamed all functions in 3.0. The early years saw a lot of churn on the way to source and binary stability. And before that there were years of development before Apple announced the project at all. (I would guess that Rust was public very early in life.) The additions for SwiftUI go overboard if you ask some of us, but that’s all version 5.
I’d say Swift is maturing on Apple platforms but is barely past experimental elsewhere. Its feature set probably looks broad for how incompletely deployed it is.
Added features (because adding features improves a language, you know!):
Really glad to see the focus on performance improvements in the compiler & type system: