Reg comments4

Tailored Swift – coming soon to a cloud near you

'Jono' Guthrie of PerfectlySoft makes the case for server-side Swift

Interview Jonathan "Jono" Guthrie, senior software engineer for PerfectlySoft, dropped by The Register's office in San Francisco to discuss the merits of the Swift programming language.

The Apple-created Swift has attracted significant attention from developers since the iPhone maker released it as an open source project last year, but interest in the language has remained flat in 2016, based on figures from consultancy Redmonk.

Swift ranked as the 17th most popular programming language in June, according to the firm.

"Swift has opened up new avenues for growth beyond iOS development via its release as open source software and the embrace of third parties like IBM or Perfect," Stephen O'Grady said in Redmonk's June report on programming language popularity, "but these have yet to yield gains in new discussion or code sufficient to propel it forward in these rankings."

Why should people consider Swift as a server-side language?

Server-side has been dominated for the last few years, previously with PHP and then more recently with things like Node.js and Rails. Rails and Node were trying to fix issues that PHP really had, and that Java had. But the problem is that both Node and Rails were slow and very, very memory hungry. And they don't scale very well.

So people had to have virtual machines that scaled vertically and then all of a sudden they have to scale horizontally and it becomes very expensive very, very quickly.

The emergence of languages like Go and Rust gave people alternatives on the server-side. But Go in particular is very C-like, very C++ like. It's a little bit more obscure. It's very structured. It works for people who have a strong background in C or software engineering.

It has the advantage over Rails and Node, where it is very fast, very scalable, and doesn't consume huge quantities of memory. So therefore you can do a lot more with a lot less resources. But it's still very C-like.

Is it as brittle as C?

In my opinion, no, it's not. It actually has a great concurrency model. Before I joined the Perfect team, I was doing a lot of Go development for about 18 months before that. So for me, in some ways, that was a reaction to the whole Node and Rails thing. And that's the reason why I gravitated toward companies, start-ups that were using Go as backend.

Then, of course, came the rise of Swift. And what I saw in Swift was a general-purpose language that didn't suffer from the same problems as Node, didn't suffer from the same problems as Rails, [which is] a framework on top of Ruby. It was very similar in terms of its profile to Go, but didn't have the same obscurity of syntax. It made a lot more sense than Go. On-ramping to Swift is significantly easier.

Plus it's one of the most-used languages in the world when you think about it because so many iOS developers are transitioning from Objective-C to Swift. So you've actually got a huge quantity of developers out there who already know the language or are already learning the language.

It's not just a general-purpose programming language, not just an iOS language, but actually something that's going to work awesomely well in the data center.

Where does Swift stand in terms of availability of packages and libraries that extend what it can do?

That's actually a common question I get asked. In terms of the server-side stuff, most if not all of the core stuff is there and is being battle tested ... We're still in the very early stages of this whole movement.

Then you start looking at all the things around that. You've got the core of the framework, the core libraries that you always need. There's HTTP, there's the parsers, the database connectors, the ORMs. There's the authentication layers. All these sorts of things, they're all there. But ... say you want to have the ability to validate an email. You know you don't want to necessarily write that yourself. Right. So with Node, with Python, with all of these other sorts of languages, with Go, you just go to GitHub and grab some code or import it as a dependency. These things are the challenge for server-side Swift.

Swift just got its first package manager.

That's right. On the client-side there's CocoaPods and Carthage.

When I've been doing projects that are extending the core of Perfect ... instead of once again writing my own library for it, I went out and had a look at GitHub and there's a whole pile of stuff out there, a whole lot of libraries for client-side iOS ... So the reality is the maturity of this is going to come a lot quicker than a lot of other language environments because it's not actually a new language. It's just a new usage of the language and maturing of the ecosystem.

But is there a reason to prefer Swift to another modern language like Go, which came out of Google, or Rust, which came out of Mozilla? Some people seem to choose based more on their feelings about those organizations than about the technical merits of the languages.

I think you're right. There are people who will gravitate toward things that from a corporate perspective they're comfortable with. So obviously if someone is, say, an Android developer, then they're, you know, drinking the Google Kool-Aid. If someone's an iOS developer, then you know they're drinking that flavor of Kool-Aid instead. So there's going to be an influence there. I think that's human nature. In a corporate environment, a lot of these things are actually driven by what CTOs are comfortable with at the moment.

Is there enough data yet to make language choices based on performance?

The performance studies that have been done – and we're now aware of three different third-party performance studies, only one of which was actually looking at memory under-load – all the rest of them we're primarily looking at raw horsepower of the language and/or looking at full-stack framework performance. And interestingly enough, Node and Ruby do very, very poorly in the raw horsepower and in the framework full-stack type comparisons.

In one particular performance study, I think at idle, it was 1.3MB for a Swift application running Perfect as a framework, at low load idle, and 15MB memory consumption for the Node application. Under load, the Swift application doubled to 2.6MB. But the Node application went from 15MB up to 245MB.

[Two of these studies were commissioned by PerfectlySoft and conducted by an affiliated third-party developer.]

So you look at the sheer economics of that and the scalability of Node and Rails in particular – it means that you need to have these really big monolithic virtual machines. And then you're trying to scale them vertically, but then all of a sudden you have to scale them horizontally, and it gets very expensive.

The practicality of Swift in the data center is going to be a no-brainer.

Are the problems with Node fixable?

They're trying really hard with the newer versions of Node to fix these issues. The threaded nature of Node is going to be potentially a little harder to fix. My personal opinion is that Javascript is not a server-side language, it's a client-side language. It is weakly typed. It's got a lot of fundamental flaws. It was written not as a general-purpose programming language or a server-side language; it was written as a browser-specific thing. And the fact that someone managed to actually make it work on the server was a miracle in itself. But I don't think it was meant to be there. And so are they going to be able to fix those fundamental problems? I don't know.

Could Swift become the one language to rule them all, perhaps through transpiling into JavaScript or WebAssembly?

I think that's a five-year-out question. I think that what we may see earlier is a slightly different shift to a coherent single development language between the three major platforms that possibly matter most right now. And that is iOS, Android, and server-side. My dream is that iOS developers – instead of having to use something fundamentally flawed like React Native, trying to cross-compile and so forth, and then giving their users a suboptimal experience on iOS and Android – I actually think Swift is going to be [usable] for not just the business logic on Android, which is possible now, but for development of user interface applications on Android. And then you're going to get a massive surge in usage of Swift.

How is it you think iOS will be usable for Android development?

It's not about iOS being usable for the Android layer. I think that the UI tools will be different, but the language that you use to construct these things will be the same. I think that Google is really looking for an alternative to Java on Android. I think they and a lot of the industry are actually tired of Java on Android.

Why is that? Is it distrust of Oracle? Is it that Java itself has technical issues?

I think you're right in both those two aspects. Just how important the Oracle ownership of the IP for Java is, I don't know. I think it's an ongoing worry for Google. But I think that there are a lot of other aspects to it as well. There's the security aspect. There's the abstraction, obviously. I think that Java is not considered [to be] a modern language as much as Go and Swift.

Java actually really is the closest equivalent in many ways to Swift in being able to work across so many different platforms. Apple has done the right thing in open sourcing Swift, so much so than than the way Sun did with Java. They made Java open but not necessarily as open source as what Apple has done with Swift. If I see a bug in Foundation, I can commit code and it will get considered and hopefully wrapped in.

The way they're handling the evolution of Swift I think is brilliant ... The way Chris Lattner is managing the community I think is really fantastic ... He's managing the community, [in terms of] technical leadership, extremely nicely. I'm using him as a counterpoint to the obvious other [open source project leader], the elephant in the room – Linus Torvalds. He manages the Linux kernel community with an iron fist. Chris Lattner seems to be managing the Swift open source community very, very gently ... So as a result everyone feels as though they want to contribute.

Since we're on the subject of operating systems, have you had a look at Google's Fuschia project? Do you have any sense of what that's about?

I think that they're trying to provide themselves a set of alternatives in case the thing with Oracle goes badly. And while they seem to have won the latest round, I actually don't think this is the last ... we're going to see ... It's better for them to start exploring this now.

What's the use-case for Perfect?

Perfect is a tool kit. [I can] use it to create a JSON API or a website or a raw TCP server for IoT devices. That's all totally possible too. If I want to write a content system in Perfect I can do that. I could write a mail server that way too.

And what does it actually consist of?

It's a collection of libraries ... helper libraries. If I really wanted to [I could write everything in Swift]. But you're effectively reinventing the wheel.

When are we going to start seeing server-side Swift appearing in cloud services, something like a one-button install on Heroku?

[Jono looks at the public relations minder in attendance.] How much can I say?

As a team, we're working on some cool stuff that will make it really easy to start projects, really easy to deploy projects, and really easy to actually say, "Hey, you know, on X cloud provider, I want to actually spin something up and just go." ®

Biting the hand that feeds IT © 1998–2017