Ask HN: What is the future of Swift on the server-side?
59 comments
I have a production app live using Swift/Vapor. I created this app solely for the purpose of learning full-stack development using Swift, and so far it has been an amazing ride. The best thing about using Swift on the server if you're already an iOS developer is that a ton of models and DTOs are simply shared across your backend and your app(s).
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
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
Used Vapor/Swift in production for a good 2 years. While Swift is really one of the best languages out there, unfortunately it didn't work out.
The problem was being strongly tied to macOS & XCode, and every update may or may not break your ability to deploy the server. Vapor itself seems to be always changing as well.
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.
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.
C# with ASP.NET Core has been pretty great in my experience; it has both reasonable language syntax without that many footguns and reliable performance
I also had a terrific time building with Vapor, but I had to put down the project and then pick it up a year later… between the interim release (v2 — v4 I think) I found the my product basically impossible to upgrade, not a lot of clear documentation on the changes. I was pretty dismayed by how far the API drifted.
We step down from Heroku as well and looking for alternatives. Can you share your Docker somewhere?
Google's Go language is well suited for back-end code. However, it's a very opinionated and quirky language. If its style suits you it's a great choice. If, after looking at it for a bit, it doesn't sit well then nope.
What did you find to be quirky?
Go error handling is a bit rough. It's not hard to write the errors but they can derail my mind when I'm reading Go code. They're like walking up stairs where every fourth or fifth step is slightly higher or lower than the rest. If I want to take my mind off of them -- nope! I'm forced by their unrelenting placement to think about them again. Lots of Gophers get used to them though so it's a very subjective thing.
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.
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.
Not OP, but I find the Go compiler very frustrating. I cannot leave unused variables or unused imports here and there… which means I cannot have fun writing throwaway code while “hacking” on personal projects. Sometimes I just want to open my text editor and write code while getting quick feedback from the compiler, but Go literally takes away the joy of coding for the sake of coding.
Besides that, I like the language to some extent.
Besides that, I like the language to some extent.
Not OP, but at the very beginning I found quirky:
- 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.
- 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.
Ah ok. I see those a lot and was just curious if there was anything new or unresolved. It's a fine language. If you enjoy Rust or Zig, I'd recommend it on your day off.
Non-existent unfortunately. Swift hasn't taken off outside of the Apple ecosystem, which is of course heavily client focussed. If you like the look of Swift, but you're writing backend code then I would definitely recommend Rust. It's actually super nice to work with. Not at all like C++.
Other alternatives would be Kotlin, C#, Go, or even Java.
Other alternatives would be Kotlin, C#, Go, or even Java.
I‘m also a rust enjoyer but if OP is a swift fan, I’d say kotlin feels the closest to swift
(Disclaimer: I am a member of Apple's Server Side Work Group (SSWG) and these opinions are mine and mine alone)
We (Transeo [1]) use Swift and Vapor to power our application which serves millions of users and regularly hits 20k requests per second. We're running on substantially less hardware than we budgeted for, which is great, and the performance is also notable - our p99 response time at peak rps is ~250ms.
That being said, performance isn't the only thing that you should look for when choosing your backend language/framework, as you've noted. We've been using Swift/Vapor for more than 5 years now so we've seen the community grow alongside it, and I am really excited about where it's going. While the ecosystem at one time was a bit of challenge (in terms of finding a package to do something, etc), over the last ~2 years we have rarely run into problems finding code snippets or packages to accomplish our tasks. We do a lot of bulk CSV processing (hundreds of gb's at a time), SFTP transfers, PDF generation/merging, calculated database locking, all of which has been relatively seamless ecosystem-wise. Check out the SSWG projects [2] for some more cool stuff happening in the ecosystem.
Hiring has been fine as well - we have a number of developers on the team that did not have Swift or Vapor experience coming in and were able to map other frameworks on top of it and pick it up quickly.
All of that being said, I will admit that I am biased on this topic :) Frameworks and programming languages are merely tools in your tool-belt, and different tools are right for different workloads.
[1]: https://gotranseo.com [2]: https://www.swift.org/sswg/
We (Transeo [1]) use Swift and Vapor to power our application which serves millions of users and regularly hits 20k requests per second. We're running on substantially less hardware than we budgeted for, which is great, and the performance is also notable - our p99 response time at peak rps is ~250ms.
That being said, performance isn't the only thing that you should look for when choosing your backend language/framework, as you've noted. We've been using Swift/Vapor for more than 5 years now so we've seen the community grow alongside it, and I am really excited about where it's going. While the ecosystem at one time was a bit of challenge (in terms of finding a package to do something, etc), over the last ~2 years we have rarely run into problems finding code snippets or packages to accomplish our tasks. We do a lot of bulk CSV processing (hundreds of gb's at a time), SFTP transfers, PDF generation/merging, calculated database locking, all of which has been relatively seamless ecosystem-wise. Check out the SSWG projects [2] for some more cool stuff happening in the ecosystem.
Hiring has been fine as well - we have a number of developers on the team that did not have Swift or Vapor experience coming in and were able to map other frameworks on top of it and pick it up quickly.
All of that being said, I will admit that I am biased on this topic :) Frameworks and programming languages are merely tools in your tool-belt, and different tools are right for different workloads.
[1]: https://gotranseo.com [2]: https://www.swift.org/sswg/
Given your criteria, Go might be a good choice maybe. It has a bigger or shall we say a more "successful" backend story.
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/
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/
Swift's performance is a mixed bag, and can be closer to JavaScript than C++. It heavily depends on how you manage your objects and how many memory allocations and copies that causes. Swift prioritizes nice syntax over implicit overheads, so it's something to look out for.
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.
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.
Amazon Prime, Mercedes and allegro have been using it. There is a conference happening soon, so you can get more inform https://www.serversideswift.info/
Very surprised that any serious company was actually using it for real application. Can you provide links to some post giving more details ?
Currently using Swift for a side project. It's "server side" in that I have a server implementation that runs on an iOS device and in Linux on a server. Using SwiftNIO for the server pieces, as it's from the Netty folks, and I really like their design.
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.
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.
> backend for my project
> 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.
> 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.
> While Swift is a nice language, it is still a 2nd class citizen on non-Mac systems.
What makes it a second class citizen?
What makes it a second class citizen?
I’m a huge Swift advocate, even on the server, but I have to admit Swift for Linux feels like an afterthought sometimes.
For instance there are still no official Debian-based Swift docker images, and the “stdlib” (the Foundation module) is very often behind the (private) macOS’ one (still no support for async/await, lots of bugs that take time to be resolved, etc.)
Things do get better with time and developing for the server with Swift is a great experience, but it still feels a bit early.
Things do get better with time and developing for the server with Swift is a great experience, but it still feels a bit early.
The complete lack of any explicit support from linux vendors and cloud providers.
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.
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.
Adding on to the other comments, swift on Linux also does not have some frameworks like Combine
Its future is the same as its present: niche server-side choice only used by Apple-adjacent developers.
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.
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.
As a fullstack dev, focused on ios dev for the past 10 years, i'd say swift for anything other than ios/macos dev is pretty much experimental.
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.
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.
I've used Swift for iOS development and generally like it. There's no technical reason why it couldn't be great for server-side development but there are two major reasons I wouldn't expect it. First, there's no painful gap to drive adoption. Go and bit by bit Rust are both reasonable statically typed, compiled languages with good ergonomics and performance. Second, there isn't a strong community of corporate and individual developers supporting use outside of iOS. That means few people, but also little tooling. I was excited by the extensibility and some of the stuff the TensorFlow team was doing but there just doesn't seem to be enough reason to pick Swift over one of the more mature alternatives. Even on Apple's own platforms there's only full support for the latest macOS release. I'm guessing the calculation is that iOS is a big enough carrot to keep a community of Swift developers around and Apple doesn't see growing beyond that as a priority. Fair enough.
> What are the other alternatives, Nim?
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.
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 similar to Swift: a language mostly famous for mobile apps, but with ambitions to be a general-purpose backend language.
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.
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.
What is the nature of your project that you need a “systems programming language” server-side?
Asked differently, why are Java (or a mature JVM language) or C# not a good fit?
Asked differently, why are Java (or a mature JVM language) or C# not a good fit?
IMO the better alternatives would be Go, Kotlin or C#. Much better ecosystems where you won't have to keep reinventing wheels.
Of those languages, only Go could be argued to be “systems” and even then not if the GC is a deal breaker.
OP wants a systems language.
OP wants a systems language.
> 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.
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.
> performant, statically-typed, systems programming language
And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.
And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.
I'm pretty sure that the objc.io[0] people are using it for their site. Much of their SwiftTalk series[1] covers work on their backend. They are fairly serious players.
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
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
I was also interested in server sided Swift for a bit but didn't go very far with it.
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.
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.
Seems like you know the answer. It probably depends on what your goals are…
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.)
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 also been keeping an eye on it for the past couple of years, but without significant outside commitment, I'm hesitant to do anything serious with it.
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.
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.
I have a couple which others haven't mentioned yet. I have very little/no experience with them, but what I have read about them matches your criteria, so they might be worth a look.
Crystal (like Ruby but fast and statically typed)
D (a "better" C/C++ with GC)
Pascal (a C/C++ competitor which has fallen out of favor, but is still being developed as FreePascal)
Crystal (like Ruby but fast and statically typed)
D (a "better" C/C++ with GC)
Pascal (a C/C++ competitor which has fallen out of favor, but is still being developed as FreePascal)
We (steamship.com) use Swift on the server to power our Heroku-style AI apps platform.
It’s been mostly great. Only downside is the server-side swift community is smaller than others, so you don’t get the deep software library selection something like Python would have.
It’s been mostly great. Only downside is the server-side swift community is smaller than others, so you don’t get the deep software library selection something like Python would have.
> But C++ has become somewhat an over-engineered language that is mostly in a to-be-not-to-be state of feature development.
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.
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.
Dart has some backend projects and support and is statically typed.
See Very Good Ventures own Dart Frog:
https://github.com/VeryGoodOpenSource/dart_frog
See Very Good Ventures own Dart Frog:
https://github.com/VeryGoodOpenSource/dart_frog
Not really a fan of the language, nor necessarily a fan of the decision, but “rust in the Linux kernel” should probably tell you the future of systems languages and suggest a re-evaluation of the language.
I think you're misinterpreting the direction of Rust.
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.
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.
My current problem with rust is the dependency hell. Hundreds of sub dependencies for every top level one. Yes some of them are super common like serde or rand, or oddly some crate that seems to be just to create directories on the filesystem?! A blessed subset of crates is what I was counting on to save the day, but when something like tonic brings in 100 or so fine grained one-off sub dependencies I don't think that can work. Right now I am just plugging my ears saying "my code is memory safe and I am fearlessly concurrent!" But I am thinking "what horrible thing is lurking in the depths of my dependency tree and which state actor put it for later?" If that seems paranoid look at the recent issues with pypi malicious packages. I know I can roll my own, but that cost money, and if tokio or tonic didn't exist, and crates wasn't so darn easy to use, maybe google would have made a monolithic grpc crate instead?
I'm not sure how substantially different that is than a single large dependency with dozens of people with commit rights.
In large projects other developers usually perform code reviews.
And even if not, there's a higher chance someone else will notice some sketchy code while working nearby.
https://www.infoq.com/news/2021/11/rudra-rust-safety/
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.
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.
Some do, and some don't. Are you confident the ones you rely on do for every single commit?
Swift is also more memory safe than rust, which I imagine is another big reason to use it.
The list is long. If you're familiar with c++ take a look at C#. Go and Java are safe bets as well. Beyond that there are a million backend languages out there.
Swift on Server has become quite mature over the past years. The ecosystem features a libraries for a lot of tools you want to integrate. Furthermore, it is being used in production by some major companies besides Apple, e.g. Amazon has a bunch of production services running on it.
One of the greatest things about Swift on Server is not only the language but also the community. They are very open to new joiners and try to help whenever possible. Furthermore, with the latest Swift features such as Swift Concurrency it looks even more promising.
Source on Amazon running Swift services? Excuse my doubt, but I've never heard of that and it seems very unlikely to me.
Use TypeScript/Node. It might be system enough for your purposes, and typed enough also.
For backend I switched
from Swift using https://www.perfect.org/
to Rust using https://github.com/http-rs/tide
from Swift using https://www.perfect.org/
to Rust using https://github.com/http-rs/tide
Crystal is pretty hot for server side applications.
So I was wondering if anyone here is using Swift and or Vapor for backend development?
What are the other alternatives, Nim?