Ask HN: What is the future of Swift on the server-side?
I am in a dilemma on which language to choose on the backend for my project. I am looking for a performant, statically-typed, systems programming language. I know C++. But C++ has become somewhat an over-engineered language that is mostly in a to-be-not-to-be state of feature development. So I looked at Rust and it already seems going in the direction of C++. So I looked at Swift, and I like what I see, but I am not sure if the language has any serious users on the server-side. IBM was one who was part of the group working on server-side features of Swift, but left the group sometime back.
So I was wondering if anyone here is using Swift and or Vapor for backend development?
What are the other alternatives, Nim?
59 comments
[ 2.7 ms ] story [ 123 ms ] thread> a performant, statically-typed, systems programming language.
What is your project about? What are the latency requirements? How many concurrent users you expect to have? If these numbers are not high, why are you not using a general purpose language like go or Kotlin?
I used vapor for a evaluation project a while ago and abandoned it quickly. While Swift is a nice language, it is still a 2nd class citizen on non-Mac systems.
You can do a small PoC project and see if you like it.
What makes it a second class citizen?
Things do get better with time and developing for the server with Swift is a great experience, but it still feels a bit early.
For more popular languages you get predefined templates for serverless platforms and compiled binaries directly in the linux distributions default repositories.
In many ways the outside interest in swift died down even quicker then the interest in running ObjectiveC outside of the Apple Ecosystem did, and as the Apple ecosystem don't include an server platform all swift server-side code is running outside of the apple ecosystem.
The problem likely isn't that swift is bad just that it's unremarkable once you take it outside of an iOS context.
Swift is a really nice language, much easier to skill up than Rust and MUCH better ergonomics, but again, IBM pulled out and the working group moves at a glacial pace...
I'd be curious to hear as well if there are any corps quietly relying on it.
For myself, I won't use it on the server, but that's because I write servers for relatively low-cost, limited-skill, demographics. I use PHP.
[0] https://www.objc.io
[1] https://talk.objc.io
If you intend to make money and or invite a team into the project over time then maybe look for something lots of people use (.Net Core, C++, TypeScript, Java, etc.)
If you want this project to be a labor of love that is mostly powered by you then pick whatever esoteric thing you want that fits the bill (again sounds like you know the options, Rust, Crystal, Nim, Server Side Swift, etc.)
I have deployed my backend on a tiny DO droplet using Docker, and it just works. There was a slight bit of learning curve for deploying it, but I can now create images locally on my Mac and pull them remotely for a fresh deployment/migration in less than a minute. Being able to build locally using Docker for Mac also means that the speed is great.
Before that, I had the app live on a Heroku setup but it cost quite a bit.
My app is at https://apps.apple.com/nl/app/instint/id1454800508
Inter-op with various web-services is often quite a headache too. Sometimes there's support for Swift or even an official SDK, but it's often not so straightforward to actually get it working. You're definitely in untreated territory here, and it shows.
So we moved NodeJS. I feel Node is a meme at this point, but man does it simply work. There are code snippets for everything and usually it doesn't take longer then 30min to figure out how to do something.
Regarding Swift I am not sure how popular it is for the backend, you might not have a lot of libs for example for doing common things. Also no idea well a Swift backend performs under load. Swift is a nice language for sure, maybe if you can risk it, go for it but keep also this in mind - https://boringtechnology.club/
- checking for "if err != nil {" boilerplate
- having $GOPATH instead of using the current directory when setting up a project. This one is not a problem anymore I believe.
Some other (well known) quirks are:
-- Forced code formatting for everything. If you don't like it you'll probably never like it. It's mostly a problem if you're switching languages often.
-- Lots of little things you'll stumble on that have to be internalized. Loop parameter scope, variable shadowing, randomization of map iteration, the way slices spring to life but maps don't, colon-equals with multiple variables, no unused variables, etc. There are lots of "Go Gotcha" lists around and I believe there's even a book about them. Every language has them but they're especially noticeable in Go because (1) the rest of the language is so easy to pick up that they tend to stick out and (2) they can't be fixed because Go has a backwards compatibility guarantee that no breaking language changed will be introduced.
Anyway, I really enjoy Go. None of this is enough (IMO) to prevent anyone from at least giving it a try and seeing how it suits them.
Besides that, I like the language to some extent.
See Very Good Ventures own Dart Frog:
https://github.com/VeryGoodOpenSource/dart_frog
If you really really need something high-performance, then Rust is the main contender. Don't be fooled by superficially similar angle brackets syntax. It's not similar to C++, it's is not even a C-family language (closer to ML). Things like having multiple string types may seem like the same mess, but it's not a legacy baggage like in C++, but an explicit meaningful choice exposing ownership and encoding semantics.
If you merely need pretty good performance, go for golang. It's very successful for services.
I don't see room for Swift in server-side languages. It won't be able to shake being Apple's technology first, and having Linux support as a second class. It's not low-level enough to beat Rust on performance. It can't compete with popularity and ease of use of JS/TS and golang.
Such a squandered opportunity on Apple's part. In the early years, the Swift team talked a big game about wide industry adoption goals, but multiplatform seems to just be a defeated box-ticking exercise now.
People say Apple are an unstoppable marketing machine, but they did an absolutely horrific job of engaging the wider software development community with Swift.
Other alternatives would be Kotlin, C#, Go, or even Java.
The community tries to expand swift's horizon with all its heart, but as long as apple is the main force behind the language there's going to be no real incentive for it to become a serious contender on other platforms.
I'd recommend go, if it's a serious project you plan to maintain for years.
OP wants a systems language.
OP is describing they want to write a backend, not a operating system. "Systems language" might have been a "kinda" specifier, rather than precise.
Go, Kotlin, C# or even Java works just fine for backends. If I were OP, I'd use whatever I know best, or is the most similar to what I know best. Unless I want it to be a learning experience, they I'd chose the language that is the least similar to the languages I know.
And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.
I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.
So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.
Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.
You should check out Kotlin. Design-wise, it's very similar to Swift, but it has a bigger userbase on the backend and an (imo) more promising future.
Kotlin is probably a few years further into its journey. There's some server-side Kotlin being written, but I wouldn't say a lot.
Rust 1.65 didn't add a new feature, it removed a limitation on an existing feature.
That's the direction I want my languages to be going in.
Over 200 memory safety issues were found in public crates in rust.
If code reviews were all it took to ensure memory safety, then we wouldn’t need the borrow checker in the first place.
Java is the "obvious" choice for statically typed web backends. Personally I'll recommend Go and C#. Both have a low learning barrier to entry, check your boxes for backend languages, and have ample resources online. I would choose C# (on ASP.NET Core) if you want flexible typing and inheritance, and Go if you want "simple" imperative code. Rust is also popular but I don't know enough to comment on it.
You can say the same for Swift. But just like with C++, you can always stick to simpler and smaller subset and make great things with it.
Asked differently, why are Java (or a mature JVM language) or C# not a good fit?