Ryan Collins

This is from 2016 -- Swift and the toolchain has gotten dramatically faster since then, but this is a comparison of server-side swift frameworks with Rails/Laravel/Spring/Nancy/etc: https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-1-inp… ...and part 2 here: https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-spe… And here's summer 2017 benchmarking/comparing server side Swift frameworks vs. Node: https://medium.com/@rymcol/updated-benchmarks-for-the-top-server-side-… Swift is a great language. Hello World in Java: public class HelloWorld { public static void main(String[] args) { // Prints "Hello, World" to the terminal window. System.out.println("Hello, World"); } } Hello World in Swift: print("Hello World") Obviously Hello World is trivial, however that comparison is indicative of the elegance -- it has power similar to C with ease of use similar to scripting languages.

I just wrote a swift api that I'm running on Ubuntu 16.04. I wasn't hesitant to use swift because first, it substantially outperforms node on many benchmarks [1] [2] and second, the community of people who are excited about swift seem to have made up for its young age. You can find workable tutorials and help online for server side Swift. And there are multiple backend frameworks to choose from. Having type safety on the server is as great as it is on the client. It's also great to be able to write the server in the same language as the client. Makes for a VERY smooth dev process. Why wouldn't you use swift on the server? (my guess is fear of new tech -- which can be healthy many times but, IMHO, at least in the case of server side swift, it may be a bit irrational!) 1. https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=swift&a… 2. https://medium.com/@rymcol/linux-ubuntu-benchmarks-for-server-side-swi…

But it is true? https://medium.com/@rymcol/benchmarks-for-the-top-server-side-swift-fr… Perfect (Swift) kills Node.js - which means it kills other stuff (like Ruby) without question. Python would be hard tho...

Just to add to this, probably the biggest, most important reason to have language-level concurrency primitives is the 3rd party package ecosystem. In Go, Erlang and Nodejs packages don't need to make any decisions about what kind of concurrency to use. The postgres driver in go will expose a blocking API, and the postgres driver in node will expose a continuation-passing-style API, or use promises. Everyone who uses those languages already knows how to consume those APIs. In these languages its very hard for an experienced developer to make concurrency mistakes - you can instead spend all your time thinking about the actual problem you're trying to solve. In C, Swift and Rust this isn't true (yet). Despite all three of these languages having lots of tools for concurrency, the lack of standardisation means you can't just grab any postgres library. You also have to look at how that library does threading and figure out how to correctly integrate it with the threading model you're using in your own code. (Does it depend on tokio? Does it use posix threads? GCD? Green threads? Async?). This turns the 3rd party package ecosystem in these languages into a fragmented minefield. As far as I know there are 4 main swift-based http server libraries[1] at the moment. Each one works slightly differently. Because they all roll their own concurrency tools, they're all mutually incompatible. Each one has implemented its own static file server, its own hsts header middleware, its own json…