Recorded – 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.
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.
“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."
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."
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.