What's the most exciting feature of future Swift?

Recorded April 9th 2020 – watch the full episode on YouTube.

‌ Swift is not standing still – what are you most excited for in the future of Swift going forward from today?

Daniel Steinberg: So the function builders is something I'm very interested in seeing land. They're doing interesting things like with Google and I don't know if they'll keep doing it. With the Swift for TensorFlow team putting the differentiability upstream. And I don't know if they'll continue to do stuff like that with other companies or with Google, so they're definitely looking at applications there.

I don't know anything about server side Swift, but with Vapor 4 shipping, that might be a good time to check that out. And so that's the additions to NIO. And I kind of think of Swift and NIO, the server-side things because the server side is also open-source as being important, especially in this post-IBM-being-involved time. It's very important that things move forward there as well. So Swift itself, I don't know. Are there wish lists that you have?

"The function builders is something I'm very interested in seeing land. They're doing interesting things like with Google and I don't know if they'll keep doing it. With the Swift for TensorFlow team putting the differentiability upstream."

Paul Hudson: I've got stacks of wish lists. Actually Prathamesh Kuwakar again asked a question, even simpler, “what is the one feature that you think would headline Swift 6?" Because they Ted Kremenek published that “Road to Swift 6” forum post. It said, “listen, there's lots things we're going to work on, lots of ideas and so forth." But it seemed to me a little bit at risk of the same trap that Perl 6.0 fell into.

It's a distant unknown land. Or even do you remember Python 3000, before Python 3 shipped? Not trying to curse it with a Perl reference, but it took them a long time to ship Perl 6 because they had such lofty goals for it.

And Python 3000 was for a long time somewhere where Guido van Rossum would punt features to – “we'll look at that in Python 3,000." When it came to it, they actually got through it very well and Swift 6 could become that, because if Swift 6 means a landmark change in the language, what is that going to be? What would a major feature look like in Swift to justify not 5.3, not 5.4 or 5.5, but Swift 6?

“The generics being rounded out would be something that I would love to see. Just generics being stronger in our language.”

Daniel Steinberg: I was under the impression that we weren't going to see that many before 6, that we would see some more dot releases. The generics being rounded out would be something that I would love to see. Just generics being stronger in our language. I'm sorry they took a lot of currying stuff away; they took it away because they said no one was using it. I think they took it away before people knew to use it, and so people weren't thinking that way.

I think that's a shame that they took that away. We keep hearing that async/await will be part of it, that the ownership and await will probably be part of 6, and people are waiting for that. But there have been recent posts lately from people saying, “I would rather see X than asynchronous. This would be more important to me.” And a lot of those around the generics.

Paul Hudson: My choice is absolutely the asynchronous stuff. It's done so very well in C3. It's even done well in JavaScript these days. Async/await and what it does to your code, how it simplifies your code and also it forces the complexity somewhere else, right? It's still doing all the magic of GCD behind the scenes for you, but it's things you don't have to think about. And that way of working, that simplification of the mental model is huge.

It's a consistent problem that writing good multi threaded code is hard. We know that. It's interesting seeing so many of the iOS 12 performance enhancements in Foundation came from taking multi threaded code and making it single threaded code. It just avoided the headaches of locking and so forth. But it's obviously also the case that devices just haven't more and more cause. We're not going ever in the other direction back to single core CPUs, again. Eight cores is fairly standard today. I think 16 cores will be standard soon enough. We've got to keep on using them somehow to be power efficient. So if we can make that easier as a programmer to use these cores effectively without adding more brain work to think about, more things to keep hold of...

And I know GCD is good, but it's not as good as async/await. Async/await is just beautiful and flat and simplifies things and pushes the work somewhere else. For me, that's far and away my number one wish list feature, async/await.

“The other thing is Clojure does some very clever things in the way they manage these huge graphs, and I don't know if Swift can do some of that. So you look at what they've done with reducers and transducers and it's just brilliant.”

Daniel Steinberg: Well. If they do it right, we won't have to think about it as much as you might think. I think that with GCD that for loops, you could iterate over an array using the closures and the callback, and then they reimplemented that using GCD without us ever feeling it. And so I'm hoping that the async/await will be such that if you need to explicitly use it, you can just like ownership models but if you don't, it just will won't for you.

So I don't know if we're going to get the Rust ownership or we'll finish up. We heard about that from John McCall, what? Three years ago? And so these are sort of fundamental things that you hope will be in Swift.

Paul Hudson: So speaking of Rust, it's very interesting because my friend, you know him as well, Benedikt Terhechte, a wonderful chap who is also a keen Rust developer, has done a number of benchmarks comparing Swift to Rust and almost across the board, Rust just sweeps Swift away. Now Swift is very fast if you compile without the safeties, for example, it'll be very, very fast. But Rust can be 100 or a thousand times faster because of that ownership model you mentioned. It knows this thing can't be changed, can't be listed and can't be copied because that's literally part of the language. It can ensure extraordinary speed, extraordinary optimizations that are currently not possible with Swift. So maybe, yes, that could be a Swift 6 killer feature, perhaps.

Daniel Steinberg: For a long time, one of the qualifications for the Swift team was that you knew Rust. And I don't know for positions there and recently, I saw Steve Breen's post, that he's spending some time learning Rust, so it's certainly in the soup there.

And he posted it publicly. I don't mind saying that. The other thing I'd say that I'd love to see from Swift and I don't know where this fits in was when they released Swift, they said, “we see this as a language from end-to-end from firmware to server to..." And I don't see it yet as a strong scripting language. I think that's a shame. And I don't know if the answer is something like Clojure, which has ClojureScript. So it's using Closure-like syntax but it's in more of a scripting context.

Not like Java and JavaScript, those were two different. They had nothing to do with each other. That was just naming. But Clojure and ClojureScript are very deliberately tied together and do some of the clever things. The other thing is Clojure does some very clever things in the way they manage these huge graphs, and I don't know if Swift can do some of that. So you look at what they've done with reducers and transducers and it's just brilliant.

“Someone knocks on your door, you want to say, "Come in." Not, "Open the door and come in.”

Paul Hudson: Scripting is complicated. And only recently, eight weeks ago perhaps, I did release a large chunk of Swift code to make it easier to do scripting with Swift. I wasn't bypassing things like type safety, that's all there. You still get protocols extensions, generics, associated types and similar, all those nice things are still there. But things like, “open this file for reading,” – it's a throwing function. Of course, we want safety, but in a scripting world would say, "Does the file exist? Yes, read it in."

That's how scripts work. We don't want to think about try catch this all the time, it gets very, very painful to write Swift scripts because it is designed for extreme safety. And scripts often are throw away things. I've got some data, I want to process it now so I can see it different way. I'll right 50 lines of JavaScript or PHP or Ruby or whatever, to process that somehow perhaps, I want do that in Swift and it makes it very, very hard right now because if you make a new file, hello.swift, you'll get no code completion in Xcode, you'll get syntax highlighting, maybe but you'll get nothing for Foundation. This doesn't work.

And it's, very annoying because I want to use Swift in more places and right now isn't able to, because of that extreme safety, just great for applications and in production, awesome. Love it. But I just want to do one quick thing with Swift in 10 lines of code, just get out the door and try something.

It's hard. So I have this whole library of stuff to do exactly that – “just trust me, I know what I'm doing. This regex is safe. I don't have to do try and catch. It's hardcoded string of regex. It's safe.” And that's not how Swift thinks sadly.

Daniel Steinberg: No, it's like the Monty Python bit: when someone knocks on your door, you want to say, “come in,” not, “open the door and come in."

Sponsor Hacking with Swift and reach the world's largest Swift community!