Hiltmon

On walkabout in life and technology

Server-sided Swift Speculation

Note: This is not a thing, it’s just some idle speculation on my behalf. But maybe, just maybe, Apple will do something like this. Or not. Maybe we will do it.

This week at WWDC, Apple surprised the developer world with their new programming language, Swift. And astoundingly, it’s almost ready for prime time Mac and iOS client software development already.

I would very much like to use a language like Apple’s new Swift on the server side as well. I suspect that we may get some of what we need there, if not all.

Note that I do not see Apple as having a server-side strategy these days. They have iCloud for hosting data and limited apps, and seem to be in no mood to compete with Azure or Amazon in the app server market. They no longer make and sell Xserve servers and Xsan storage, they no longer make and sell WebObjects, their excellent server platform, and OS X Server is just OS X with a few more applications installed. Nope, no server strategy at all. Let the Linux folks have that.

On the other hand, like gcc before it, the clang compiler is open source, available on server platforms and being added to and maintained in public by Apple. Which means that I expect Swift to follow Objective-C in being opened up, available and supported on all clang platforms. Which means Swift could compile and run just fine on Linux distributions which host the world’s servers.

Most server applications these days are built using interpreted languages (such as Ruby (Rails), Python (Django), PHP (WordPress) or Javascript (Node.js)) or runtime-based languages (C# or Java). In most cases, these are plenty fast and stable. But when speed or scalability issues kick in, nothing beats a compiled language. I believe this is why Google is switching to its lovely Go language. It compiles to native, threads beautifully and runs at fully native speeds using far less hardware for the same throughput than anything else.

Imagine if we could use Swift for the same thing. It has the flexibility of a scripting language with the raw speed of a fully compiled native language. It has a REPL and playgrounds for us to play in (not available in Go), a blindingly fast and safe compiler, and all the language features needed to build these types of applications.

Imagine Rails written in Swift for bigger front end web applications that scale and thread without pain. Imagine smaller Swift projects using the Node or Sinatra model for fast and scaleable RESTFUL web-services. Imagine a Swift-based Jekyll to create baked blogs (ok, went too far, this would be completely unnecessary as the whole web server can be compiled in). Using a compiled multi-core language to process web requests would turn things around that much quicker, and yet the language is as easy to use as our current slow-running tools are. The speed of a scripting language with the speed of a compiled language and none of the memory management, buffer overflow and pointer issues. Win-win.

I’m speculating that’s why Google developed and is investing so heavily in Go.

What’s missing, of course, is the eco-system. But that has been written before and can be written again. It would be a heck of a lot easier to write if Apple offered Foundation and a subset of Cocoa. But none of the other scripting and runtime languages we use today had these libraries to start with either and they run just fine now.

I think languages like Swift, Go or maybe Rust are the future of server side. Fast to write, yet compiled and swift running, optimized for safety, reliability and multi-threading, saving us from scaling issues and excessive server costs without increasing the complexity of the application development and support process.

But with Swift, we may be able to go further. One language to rule them all. Shared common code across desktop, mobile and server. All native, all fast, all cores used.

It would be amazing.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Comments