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.
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.
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.
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.