If the Swift folks want adoption, they're going to have to think about the broader developer ecosystem. There's also an inherent mistrust in Apple that I think a lot of engineers have. It feels a lot like Google Dart in this respect.
- support for platforms beyond Ubuntu
- fixing the myriad weird bugs on Linux (here's two particularly bad examples: https://bugs.swift.org/browse/SR-10613, https://bugs.swift.org/browse/SR-10344)
- coming up with an error handling solution for when your app crashes on the server that is better than "just have your load balancer restart the instance"
- improving compile times for large applications
- improving modularisation concerns (e.g. submodules)
- creating an alternative to Foundation (recently, foundation on Linux was split into different modules, which makes the code that compiles fine on a mac break on Linux until you add additional imports ... go figure)
Have you tried breaking up your project into more, smaller modules? Incremental builds with small modules tend to be very quick.
I agree with you though regarding the priorities of the core team. I tried to reach out to several people a few months ago to get involved in contributing to improve the Linux situation, and nobody answered my messages.
Also, Swift is just really not designed well for very modular apps. There are no qualified imports, there are naming conflicts, inlining stops working, etc.
Swift can be a great choice for backends for lots of reasons (shared code between client and server, client devs become full-stack devs, etc.), and it has its drawbacks as well.
This idea that for Swift to thrive as a server language it has to win some contest against Go and Rust makes absolutely no sense to me.
That's not the point! It's that engineers have to use Mac machines to develop Swift because they're tied to a development platform. Go and Rust (simply called out as nearest neighbors) do not have this limitation. Even Microsoft has made great progress in making their tools available on other platforms.
It would be foolish to choose Swift for this reason. You're tied to Mac machines until it's been proven other platforms will have full support. It's a real handicap for Swift as a language and platform for anything beyond writing Apple software.
That is patently untrue.
- there is no free IDE (XCode is only for macOS, and CLion costs money - plus, it has its own bugs)
- a lot of tips and tricks on the internet (e.g. about profiling your application, etc.) heavily rely on XCode. Actually, even Apple's own documentation usually references XCode settings (or other apple tools) instead of exposing a good cross-platform interface
- the code just behaves differently on Linux than it does on the Mac (especially with Foundation)
And what server side code “behaves differently”
Where does it say it’s not “production ready” on the GitHub link?
Spend a bit of time on the Vapor Discord channel and read about all the quirks Linux users have to deal with that the rest of us don’t.
(My impression is that it’s due to Foundation libs.)
I write Swift code that runs on Linux and also on macOS or iOS, and we frequently have to have sections of "if Linux, run this code, else run this other code".
And while that's trivial to write, it's not trivial to find all the places where you have to do that.
(Nevertheless, I like Swift a lot and am using it on Linux.)
Instruments, which ships with Xcode, is quite powerful.
For me, lots of string and substring operations throw NotImplemented exceptions on Linux, when they just work on Mac. This kinda sucks because there’s no compiletime or linttime warning for this.
You don't have XCode on linux, but I've never heard of someone being disappointed about that.
And does Apple have to be the source of all tooling? Is that how it is for Rust and Go? It's certainly not for Javascript and Python tools.
"failed to create SwiftPMWorkspace: could not find executable for 'xcrun'"
Until such time as there is a working installer that is as simple as "download XCode from the app store", I don't really consider that to be an alternative. I certainly can't recommend it to anyone on my team.
Swift has a lot more redeeming aspects than javascript does, but like this post acknowledges, they don't have its package ecosystem.
The following summer I got a gig doing Typescript on both client and server; mostly the experience has highlighted to me how well designed Swift feels, and how stapled on and hacked Typescript feels. Do not like.
It is stapled on, though, right? Typescript is stapled onto Javascript. There's only so much they can do. I don't mean that as an argument for Typescript, more just that there are real constraints for the language developers.
(Burn karma burn!)
I think in some ways this is a chicken-and-egg problem. If people start working with Swift in the server space, that ecosystem will quickly evolve.
Also, Swift has great interop with the C FFI, so you have access to every C library, and every Rust library with a C API to boot.
edit:
> Aside from that, does anyone think that javascript is a good language choice for backend development?
I write a lot of swift code for personal projects, largely because it's so nice to program in, and I actually think it could be a great choice for back-end development.
I think Swift offers many of the same advantages of Rust in terms of a robust, powerful type system, and the feeling that if your code compiles, you're probably not going to have too many runtime errors (as long as you followed the rules).
Swift makes tradeoffs in favor of developer ergonomics where Rust chooses in favor of performance. In the vast majority back-end cases, Swift's performance will be good enough, and it's ease of use lets you have many of the advantages of a language like Rust but with the improved productivity of working with a higher level language.
Because all three are in the spot of "what If I want C/C++ but better?". Even if are not direct competitors are in the space that a lot of folks wish to be (ie: Productive as scripting languages yet more performant)
It does have positive characteristics in that it's much more memory efficient than a lot of GC solutions. Also it's deterministic, which will be appreciated by anyone who's had to deal with Stop-the-world garbage collectors. It's also possible to avoid a lot of ARC overhead by avoiding reference types, which is often quite tenable due to Swift's robust support for value types. Also there's a lot of low-hanging fruit for how ARC could be optimized to cut into that overhead.
Anyway, not quite sure what I'm getting at, but the memory management story with Swift is interesting.
Probably if swift get more traction in server side, is where the difference from GC (that in other words, are BATCH ORIENTED memory managers vs SCALAR ORIENTED) then the need to improved things will show up.
For me, swift will be the ideal language (for syntax/style and performance ok for me). But is a deal killer that is not good on windows and no starter for android (that sadly, I need to support because is the dominant platform in my country).
If at least swift was great for backend/logic (ie: no UI on win/android/linux) it could be enough...
It's definitely more rough on Windows and Android, but at least CI is set up and passing on both platforms (which wasn't the case a year ago): https://github.com/apple/swift/blob/master/README.md
As far as taking over from Go or Rust, I don't see someone with a greenfield project picking up Swift as the basis of some arbitrary project. Instead I see someone working on a Swift-based app -- say for iPadOS or macOS -- and needing a server-side component and deciding that it enables better skill and code re-use to implement the server-side in Swift as well.