Swift could have been a big player in web development 9-10 years ago if they invested more in Linux support with a good standard library (and [0]package manager). Nowadays I would say Go is more an alternative rather than Node, maybe for some extreme cases Rust.
I wanted to love Swift, but there was (maybe still is) low Apple investment outside the Apple ecosystem.
[0] Still not sure to this day why Swift has a package manager if Xcode is not using it (or at least was not using it a few years ago), I just followed lightly Swift development the past few years.
I’ve been doing a lot of backend stuff recently with Dart after coming from a Node / Ruby background and I can’t begin to describe what a breath of fresh air it is. Insanely high quality of life improvement for development.
The experience is very similar to what people here are describing that they wanted from Swift.
Also in a similar vein to Typescript, it’s another language I can now comfortably use and share between front and backend but with a very different and I think for most use cases better set of trade offs.
Honestly I think it’s the most underrated modern language out there at the moment because people still only associate it with Flutter which is unfortunate.
Dart's claim to fame was a static type system, but TS's type system eventually surpassed Dart's and then some: TS not only gives lots of escape hatches from soundness because the JS ecosystem is messy and needs it, but it also doesn't repeat Dart's colossal mistake of making every generic type covariant then inserting runtime checks on writes (something everyone knew was a mistake after Java arrays and Eiffel did it).
Dart has some things in its favor: it's not defined by underlying JS semantics, so it's free to jettison some of its legacy (bye bye `undefined`). Unfortunately its changelog doesn't paint a picture of an evolving language.
How’s the performance story when using for backend?
I love and use go for 99% backend and node for scripts (usually there’s a npm package that does what I need - done in 10 min) or spinning up simple aws lambda.
Go is so highly performant at all things including CPU bound tasks (no point comparing io bound stuff, although it can handle a larger volume of these).
Plus the scaling story is that it just always works fast the more resource you throw at it.
I don’t use rust because I don’t need that level of perf. If rust is 10 go is 8-9. That’s fine for me. For context I have services doing 10-100k rps that cost me like $4 plus bandwidth (depending on usefase, each).I don’t need beefy instances.
Apple just did not care enough about server development to invest in it. There are plenty of languages and frameworks out there. I wouldn't say Go and Rust are particularly logical choices for web development though. Of course they are being used for that but it's not necessarily the best fit.
Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development.
People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction.
Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it.
Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc.
On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.
Swift was first released in June 2014, which is 1 month away from being exactly 10 years ago. So you wanted them to optimize it for web development as it was being birthed as a language?
I was a long time Windows .NET Framework dev and switched to TypeScript + Node for a while because that's what all the startups were using and thoroughly enjoyed it. One thing that stood out to me in particular was just how fluid it is working with types in TS and also how good the unit testing story is on Node.
Then switched back to .NET 6 when I joined another (rare) startup using C#/.NET for the backend. .NET now is a fantastic backend platform and I've been very pleasantly surprised.
Part of it is that the base framework now feels really complete and well put together -- it feels "batteries included", but with the Duracell branded batteries and not the cheap knockoffs. The Entity Framework ORM didn't seem as competent in the .NET Framework days, but now EF Core is really, really good; highly performant and ergonomic to use. Part of it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider.
What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12.
I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system.
Swift could have been a big player but equally I can’t see a particularly good reason why you'd choose it. I like it a lot as a language but unless I was really wedded to the idea of reusing code between server and native app client I wouldn’t be pushing it. For one it’s way too easy to create memory leaks compared to garbage collected languages.
Once you've worked with refcounting GC systems for a while avoiding leaks becomes pretty much second nature.
It is absolutely a pain when you first come to it from a mark and sweep GC'ed language but once figuring out the right spot to use a weak reference becomes automatic creating leaks largely ceases to feel 'too easy' though occasionally throwing a cycle checker at your code is recommended nonetheless.
re: why does Swift have a package manager if Xcode doesn’t use it:
I occasionally use Swift but almost never use Xcode. I find command line Swift tools, including the package manager, with either or both Emacs and VSCode makes for a nicer dev experience.
>A few folks asserted that the CPU-heavy nature of calculating Fibonacci numbers isn’t representative of web servers generally. Multiple people noted that – in the Swift implementation, at least – the majority of the CPU time was spent doing the Fibonacci calculation. Some felt this was therefore not a useful benchmark of Vapor itself. A lot of this boiled down to the “no true Scotsman” problem, which is very common in benchmarking, with a bit of perfect world logical fallacy peppered in, trying to identify the One True Representative Benchmark
Well, it doesn't take any True Scotsman to understand that "busy calc of Fibonacci" is a crap web server benchmark.
>Accusations were made pretty quickly that the benchmark is “unfair” to Swift because Swift doesn’t – it was asserted – have a properly-optimised “BigInt” implementation, unlike all the other languages tested. No real evidence was given for this. Even if it were true, it doesn’t invalidate the benchmark – in fact, it just makes the benchmark more successful because it’s then highlighted an area where Swift is lacking.
This takes defensiveness to the next level.
Sure, it might highlighted an area where Swift is lacking. Even lead to opportunity for improvement there.
But an even more important question is: does is say anything about what it was supposed to say (and the conclusions they drew from it), that is: whether Swift is good for web serving?
In that end, are BigInts a big part of web serving? I've used them maybe a couple of times in 20 years of web/APIs, in very specialized cases.
Instead of finding various excuses why the benchmark is not crap, maybe write a decent benchmark to begin with? One can find stupid non-relevant bottlenecks for any language (e.g. nerf Node by blocking work, find some PHP operation that's hella slow and lean on that, etc).
Maybe, but all the others are not compared with TLS - who serves web pages with Node or PHP or even Java to terminate TLS? So why would the Swift version need to handle it?
I guess one lesson not explicitly mentioned is that doing benchmarking on something like macOS can have lot of pitfalls compared to systems more intended for this kind of workload (Linux...).
But the mention of wrk immediately stood out as a red flag; there is notable problem with wrk called "coordinated omission":
The default limits of MacOS is not really web server benchmark friendly.
ulimit -a
Maximum size of core files created (kB, -c) 0
Maximum size of a process’s data segment (kB, -d) unlimited
Maximum size of files created by the shell (kB, -f) unlimited
Maximum size that may be locked into memory (kB, -l) unlimited
Maximum resident set size (kB, -m) unlimited
Maximum number of open file descriptors (-n) 256
Maximum stack size (kB, -s) 8176
Maximum amount of CPU time in seconds (seconds, -t) unlimited
Maximum number of processes available to current user (-u) 5333
Maximum amount of virtual memory available to each process (kB, -v) unlimited
Debian's limits are better:
~> ulimit -a
Maximum size of core files created (kB, -c) 0
Maximum size of a process’s data segment (kB, -d) unlimited
Control of maximum nice priority (-e) 0
Maximum size of files created by the shell (kB, -f) unlimited
Maximum number of pending signals (-i) 30744
Maximum size that may be locked into memory (kB, -l) 993336
Maximum resident set size (kB, -m) unlimited
Maximum number of open file descriptors (-n) 64000
Maximum bytes in POSIX message queues (kB, -q) 800
Maximum realtime scheduling priority (-r) 0
Maximum stack size (kB, -s) 8192
Maximum amount of CPU time in seconds (seconds, -t) unlimited
Maximum number of processes available to current user (-u) 30744
Maximum amount of virtual memory available to each process (kB, -v) unlimited
Maximum contiguous realtime CPU time (-y) unlimited
For testing I always create an instance somewhere (mostly AWS) and configure the OS to have much higher performance limits to enable better performance outcomes.
I feel like comparing performance of Vapor against Node JS in May of 2024 isn’t all I want to see. Like yes Node JS still dominates but we know other runtimes like Bun run much faster.
That part aside, I have to say Vapor kind of took over my brain for a year when I was in college. So much so that I actually built some freelance sites with it. A typed language for web development?! I loved the idea of using swift to make websites and honestly everything just worked so well—-until it didn't.
Remember Heroku? Well there was a heroku buildpack to make a vapor site build with a push to a git repo. Worked great 4 years ago. Well I’ve been ignoring heroku emails (my email is a landfill) for about 3 years and little did I know they had completely end-of-lifed the Postgres version I had been using to the point where the entire build was bricked. I could have spent like 5 hours downloading Xcode and getting it updated and working through errors but instead I just spun up a next js TypeScript site and had a working solution with code ported over (yay for static small sites) and deployed live. Today TypeScript does the job that Swift did for me back then, enabling types for web dev. Anyway, thanks to everyone who worked on or currently works on Vapor!
I don't think this blog post ever intended to provide a comprehensive comparison between Swift/Vapor and other languages/frameworks.
I think the bigger lesson from this writeup is that we should be careful when looking at these kinds of benchmark comparisons because there may be much more nuance to their results than there initially appears to be.
I think so too, I also saw it as a lesson on careful and methodical debugging. I've been in situations like the one written up, trying to debug something tricky where each team member is coming up with multiple wrong hypotheses and missing something obvious.
Yeah and it leaves out a lot of details to be desired.
For example, no debian build of Swift. And when I ported the ubuntu version to .deb, I ran into odd bugs, like when you kill it, it lives on! Apparently a known issue.
Basic _big_ bugs that shows Apple's half assed commitment to open-source on any other platform than their own. I can't blame them, but Swift on linux, beware.
Swift is a wonderful language, sadly I'm not seeing the commitment from Apple to make it ubiquitous. Also to note, Apple has basically killed macOS as a server, rendering Swift more towards a system/UI target language; which is a shame, because again, it's a wonderful, safe, language.
I find it kind of surprising that they don't put more effort behind swift-on-linux, it would make learning swift a generally more valuable skill. This increases the pool of people who would be willing to write mac software, and in particular, standalone libraries
Foundation is going through a gradual open-source rewrite by Apple and the Swift community, which is going to take a while but will eventually open up Swift more to other platforms.
Yeah I get that it's frustrating. But it is open source, and there isn't anything stopping you or anyone else from making contributions that bring the language to more places. Sure, various aspects of the project could be improved but that doesn't mean it is "half assed".
Vapor is on that list, although it has not implemented all tasks (and thus has no composite score). It has results for JSON serialization, and database interop. It places near the bottom in each task it has completed.
He's wrong about increasing somaxconn. That'll just increase 'bufferbloat' if you're service can't keep up processing requests and is overloaded. The upstream load balancer will notice far too late and keep sending you way too many requests.
Interesting article (did not finish it), however the little apartes feel soooo condescending. It's impeding the reading in my case. Might just be me though, don't pay too much of a mind to it.
Makes me wonder how the other languages/frameworks would perform if experts were also looking into them and why they were so slow. Recent versions of pure native PHP, in particular, are incredibly fast and lightweight, and I'm quite surprised by its pokey showing here.
Readit News
I wanted to love Swift, but there was (maybe still is) low Apple investment outside the Apple ecosystem.
[0] Still not sure to this day why Swift has a package manager if Xcode is not using it (or at least was not using it a few years ago), I just followed lightly Swift development the past few years.
The experience is very similar to what people here are describing that they wanted from Swift.
Also in a similar vein to Typescript, it’s another language I can now comfortably use and share between front and backend but with a very different and I think for most use cases better set of trade offs.
Honestly I think it’s the most underrated modern language out there at the moment because people still only associate it with Flutter which is unfortunate.
In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.
Dart has some things in its favor: it's not defined by underlying JS semantics, so it's free to jettison some of its legacy (bye bye `undefined`). Unfortunately its changelog doesn't paint a picture of an evolving language.
How’s the performance story when using for backend?
I love and use go for 99% backend and node for scripts (usually there’s a npm package that does what I need - done in 10 min) or spinning up simple aws lambda.
Go is so highly performant at all things including CPU bound tasks (no point comparing io bound stuff, although it can handle a larger volume of these).
Plus the scaling story is that it just always works fast the more resource you throw at it.
I don’t use rust because I don’t need that level of perf. If rust is 10 go is 8-9. That’s fine for me. For context I have services doing 10-100k rps that cost me like $4 plus bandwidth (depending on usefase, each).I don’t need beefy instances.
Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development.
People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction.
Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it.
Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc.
On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.
Deleted Comment
Go only if one is feeling like I was coding in 1990's.
Even node is better, thanks to Typescript, and if there are performance issues, native modules are an option.
Then switched back to .NET 6 when I joined another (rare) startup using C#/.NET for the backend. .NET now is a fantastic backend platform and I've been very pleasantly surprised.
Part of it is that the base framework now feels really complete and well put together -- it feels "batteries included", but with the Duracell branded batteries and not the cheap knockoffs. The Entity Framework ORM didn't seem as competent in the .NET Framework days, but now EF Core is really, really good; highly performant and ergonomic to use. Part of it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider.
What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12.
I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system.
[0] https://github.com/CharlieDigital/js-ts-csharp
https://developer.apple.com/documentation/xcode/swift-packag...
Deleted Comment
It is absolutely a pain when you first come to it from a mark and sweep GC'ed language but once figuring out the right spot to use a weak reference becomes automatic creating leaks largely ceases to feel 'too easy' though occasionally throwing a cycle checker at your code is recommended nonetheless.
I occasionally use Swift but almost never use Xcode. I find command line Swift tools, including the package manager, with either or both Emacs and VSCode makes for a nicer dev experience.
Well, it doesn't take any True Scotsman to understand that "busy calc of Fibonacci" is a crap web server benchmark.
>Accusations were made pretty quickly that the benchmark is “unfair” to Swift because Swift doesn’t – it was asserted – have a properly-optimised “BigInt” implementation, unlike all the other languages tested. No real evidence was given for this. Even if it were true, it doesn’t invalidate the benchmark – in fact, it just makes the benchmark more successful because it’s then highlighted an area where Swift is lacking.
This takes defensiveness to the next level.
Sure, it might highlighted an area where Swift is lacking. Even lead to opportunity for improvement there.
But an even more important question is: does is say anything about what it was supposed to say (and the conclusions they drew from it), that is: whether Swift is good for web serving?
In that end, are BigInts a big part of web serving? I've used them maybe a couple of times in 20 years of web/APIs, in very specialized cases.
Instead of finding various excuses why the benchmark is not crap, maybe write a decent benchmark to begin with? One can find stupid non-relevant bottlenecks for any language (e.g. nerf Node by blocking work, find some PHP operation that's hella slow and lean on that, etc).
I guess one lesson not explicitly mentioned is that doing benchmarking on something like macOS can have lot of pitfalls compared to systems more intended for this kind of workload (Linux...).
But the mention of wrk immediately stood out as a red flag; there is notable problem with wrk called "coordinated omission":
https://github.com/wg/wrk/issues/485
https://github.com/giltene/wrk2
https://news.ycombinator.com/item?id=34148502
Benchmarking is difficult. And there is lot of subtlety on how you set up the client(s) and servers that can impact the results a lot.
https://apple.stackexchange.com/questions/264958/what-does-s...
https://support.apple.com/101992
That part aside, I have to say Vapor kind of took over my brain for a year when I was in college. So much so that I actually built some freelance sites with it. A typed language for web development?! I loved the idea of using swift to make websites and honestly everything just worked so well—-until it didn't.
Remember Heroku? Well there was a heroku buildpack to make a vapor site build with a push to a git repo. Worked great 4 years ago. Well I’ve been ignoring heroku emails (my email is a landfill) for about 3 years and little did I know they had completely end-of-lifed the Postgres version I had been using to the point where the entire build was bricked. I could have spent like 5 hours downloading Xcode and getting it updated and working through errors but instead I just spun up a next js TypeScript site and had a working solution with code ported over (yay for static small sites) and deployed live. Today TypeScript does the job that Swift did for me back then, enabling types for web dev. Anyway, thanks to everyone who worked on or currently works on Vapor!
Check out https://marketplace.visualstudio.com/items?itemName=sswg.swi...
What a novel idea.
Deleted Comment
https://www.techempower.com/benchmarks
This is what would be interesting to see Vapour/Swift on.
I think the bigger lesson from this writeup is that we should be careful when looking at these kinds of benchmark comparisons because there may be much more nuance to their results than there initially appears to be.
For example, no debian build of Swift. And when I ported the ubuntu version to .deb, I ran into odd bugs, like when you kill it, it lives on! Apparently a known issue.
Basic _big_ bugs that shows Apple's half assed commitment to open-source on any other platform than their own. I can't blame them, but Swift on linux, beware.
Swift is a wonderful language, sadly I'm not seeing the commitment from Apple to make it ubiquitous. Also to note, Apple has basically killed macOS as a server, rendering Swift more towards a system/UI target language; which is a shame, because again, it's a wonderful, safe, language.
I wish them success but realistically they won't have success.
Deleted Comment