The problem of Swift in backend (August 4, 2015)

A significant part of the online discussion about Apple eventually open-sourcing Swift (the announcement has been made at this year’s WWDC) revolves around the possibility of developing backend services in Swift. The logic goes that once the code for the Swift compiler will be publicly available, it will be ported to Linux as well as every other imaginable platform out there and we’ll enjoy healthy competition between Swift, Go and (maybe) Rust in the server-side development space.

In practice, as a result of decades of earlier competition, there’s already a very strong incumbent in the server-side development space. One language that over years has emerged as a clear winner — it’s Java. A very significant majority of backend services is already written in it; new ones are added every day. Some of those services may not be visible for general public, but they power cloud infrastructures, run transactions between banks, calculate the payroll, process your medical records, keep track of deliveries and do many many other useful things that keep our lives going.

Java has attracted lots of criticism over last years. Most of it was targeted at the language itself and the (too little) progress Sun/Oracle made in advancing the language towards what is considered to be state-of-the-art in programming languages development. Java’s runtime was rarely under heavy criticism. Still, after decades of heavy use in very diverse fields, some areas for improving the JVM became clear too, such is the need for even more predictable garbage collector, value objects, very large heaps and off-heap areas, and so on. In almost a cathartic move, Oracle released Java 8, which addressed some of the problems with the language and the JVM, and was received with great enthusiasm, as far as I can tell (if you’re interested, there’s a video of Brian Goetz talking about the tradeoffs they had to make when pushing Java 8 for release).

So, from a practical perspective, Java is now good enough language for server-side development in many regards. In this situation, both Go and Rust are doing a great job addressing issues that may still represent pain points for Java programmers. Go shines at lightweight predictable concurrency. Rust minimizes an overhead of a runtime while introducing its own safety features. Situations like this are always an ultimate test for the incumbent: if current underdogs are massively outperforming at those pain points, the incumbent is at risk of becoming irrelevant. And this is good.

The sad truth about all this is that when a company wishes to own an entire development stack, like Apple probably will want with server-side Swift, they can’t focus on a single pain point — their language should perform equally well over the whole breadth of their development efforts. Which means, for example, you can’t dismiss garbage collector as there are way more programming problems that benefit from GC, than those that suffer from it. And Swift’s reference counting memory management is definitely not on par with the advanced garbage collectors in existence.

Moreover, to introduce a production-quality garbage collector into new language runtime is an enormous task. To do this would mean to repeat most of the effort LongView (the company behind early Smalltalk and Java virtual machines), Sun and Oracle has put into the JVM since the late eighties. This is truly a Herculean task, that even the largest tech companies can’t pull off easily. So, if Swift in backend will ever start taking off — and it undeniably will, if it’ll ever be released, — we can witness a generation of programmers thinking that marking fields as weak is the best memory management technique out there.

Am I the only one sad about this?