I’m not convinced Swift is going to be a long-term hit in server software.
- It’s faster and uses less memory than some other technologies.
- It has the potential to reduce communication errors when used for both the client and the server. Chris mentions the Mars Climate Orbiter as an example of such an error.
I personally don’t find these arguments compelling.
First of all, plenty of extremely popular technologies are not the most performant technologies. You choose them because they’re easier to develop in, easier to maintain, easier to keep up and running. If we wanted the very fastest, we’d still be writing server software in C.
Second, most current server software is written in a different language, and with different libraries, than the client software it talks to. People know how to solve this problem. Hint: switching to a new language isn’t necessary.
Third, native iPhone and Mac apps are an important but not overwhelming subset of the clients a server has to talk to. The Swift advantage vanishes if we’re talking about Android or Windows or web clients.
So is Swift going to be easier to develop in, easier to maintain, and easier to keep up and running than its competitors on the server?
Making it those things for server software is certainly not Apple’s priority. Their goal is to make it work for them, which means low-level OS software, frameworks, and native application development.
IBM can try to do this work. Chris’s talk is all about the extra steps they’ve taken, the extra projects they’ve written, to do just that.
But at some point, as part of their effort, IBM is going to want something from Apple, something from the Swift development effort, which clashes with what Apple thinks is important.
Who’s going to win that clash?