Road to Swift 6 video
I shared a very special video on my Following Swift Evolution video series the other day, Road to Swift 6! I think it’s an important moment to look at what the future of our beloved language looks like so I spend some time cleaning up a transcript of the video to have it posted in this blog, for posterity.
Hello everyone and welcome to this video where we’re gonna explore the Road to Swift 6. I’m very excited for what is coming so this video is very special to me.
Ted, from the Swift Core Team, made a post on the Swift forums talking about the goals for Swift 6. So it seems like a good oportunity to discuss what’s coming and what I’m most excited about.
But before we focus on the future, it is important to surface the big gaols that have been accomplished already, so we have a clear picture of the position we are on before focusing on what’s next.
Of course we had many language improvements and great features, so making a list here would be too much. But there are 2 specific things that make now a good time to discuss what the future looks like.
The first one is ABI stability. Even if it’s not a big deal for platforms outisde Apple, this was a main focus for the engineering team at Apple and it has been going for a while, being Swift 5 the big release for it. Now that it’s done it means they can focus on more big things.
The other big accomplishment is the Swift Package Manager, which has been integrated in Xcode and includes better support for other IDEs. This provides to the Swift community a common and cross-platform solution for building and distributing Swift libraries. This is a MUST if we want the langauge to grow.
And that’s the point, with the introduced features and a good base for the ecosystem now Swift is in a good position to grow and expand.
So what’s the deal with Swift 6? The Core Team likes to focus on themes for every Swift release. These are the broad topics that the Core Team would like to see Swift 6 tackle. It doesn’t mean that other features won’t be added of course, but this servers as a guide to know what to prioritise.
- Accelerate growth of the Swift software ecosystem
- Create a fantastic development experience
- Invest in user-empowering language directions
It is important to understand that, as with many existing features like ABI stability, a specific feature is not the work of only a single release. Features are worked trough mulitple releases and shiped only when they’re ready.
This means that some things we will mention are already being worked on (like the ownership model) but the important thing is that the core team expects Swift 6 to be the culmination of a bunch of those. So we will see more 5 point releases until everything is ready for a big major release.
But let’s dive into each theme because there is so much interesting things to talk about!
The first major theme is to Accelerate the growth of the Swift ecosystem. Swift is the the facto language for Apple platforms, and is growing in other domains (like services and server side or machine learning with Swift for TensorFlow and Apple’s own frameworks). But the core team wants to focus on accelerating this growth and making Swift available for EVERYONE.
- More Platforms
- Improve installation and deployment of Swift software
- Support cross-platform tooling
- Cultivate a rich open source library ecosystem
- A package registry?
The main thing that a language needs to keep growing is to expand the number of platforms where is available and supported. Some community members have done a great work on this, like supporting other unix systems, Arduino or even the port to Windows (the responsable of which, is now part of the core team!). But it would be great if the Swift project had official support for all of this. This would mean integrate those into the main compiler, CI infrastructure, official releses and documentation. I personally would love to see an easy to support Windows and official support for WASM.
An important diasctintion to make here is that we’re not talking about supporting other Application Platforms, this would require huge efforts on UI frameworks that are outside of Swift.org, the focus here is on making the language available on more platforms, which, of course, is the first step for anything bigger to occur.
The next point is to Improve how software written in Swift is installed and deployed. I rarely use Swift software that doesn’t come in form of an App, which is easily installed, or that I run myself from a binary as a CLI. But it would nice to see improvements on this last use case and specially around server code deployment.
Tooling is a really important part of any programming language. So the next focus is about Supporting cross-platform tooling such as the Language Server Protocol, things like, code formatting and refactoring, and of course the Swift Package Manager. Right now I’m perfectly fine with using Xcode for Swift development, I think is a great IDE and is my main tool, but it’s true that having more options is always a good thing, specially for people that will mainly target platforms where Xcode is not availalbe, and the Language server protocol is a great solution for this. And of course, the Swift Package Manager, right now is the way to go, it’s so nice to use, specially with Xcode integration, that we can say we finally have a decent official package manager. But there is still lots of things to improve so any progress here is always exciting.
And probably the most important point of all of this: Cultivate a rich open source library ecosystem. I think this is the key. Other languages have such a huge number of libraries, providing solutions for so many problems, that sometimes Swift can’t compete with. In my opinion this is the main reason why someobdy would pick another language over Swift, so we must do better here, quickly.
The goal for the Core Team here is to help cultivate libraries that help on specific domains. For example SSWG is helping with libraries for services, or the release of Swift Numerics which is a big boost for Swift in scientific scenarios.
But the question is, how can we encourage great libraries? The SSWG is doing a good job with this thanks to its incubation process, maybe this can be expanded to other domains.
And one thing that is not mentioned here is a package registry. This is something crucial in my opinion. GitHub announced Swift package integration but I still haven’t seen anything public about that. Let’s hope this is not forgotten.
Moving on. Growing the langauge won’t be worth unless developing with it is a great experience. So I’m glad this is another main theme for Swift 5.
Simply put, developers should be both highly productive and experience joy when programming in Swift.
Ted Kremenek, On the road to Swift 6
This is a direct quote from the forum post and IT IS great! In my opinion Swift is a joy to program in, is the language I have more fun with and it makes me use it not only for work but also as a hobby.
I was talking with a friend about languages, and the topic of making games with Unity came up. I love making games with Unity, and I like C#, it’s a great language, but at the end of the day i’m more motivated to work with Swift. Is as simple as that.
But is true that the experience needs to get better, compiling time is one of the big hurdles so I’m glad is the first thing the core team mentions.
- Faster builds!
- More informative and accurate diagnostics
- Responsive code completion
- Reliable and fluid debugging experience
Faster builds! Who doesn’t want that! Not publicly announced yet, but checking GitHub you can see how there is work going on already to significantly improve the performance of incremental builds, they are doing some refactors to have a more precise dependency tracking in the compiler itself.
Diagnostics! Another crucial aspect of a compiler. There is a blog post on Swift.org that goes into great detail about this new system, and Xcode 11.4 is already improving them so much. Diagnostics were one of the big issues on early swift versions, on Swift 5 there were not that bad, but then SwiftUI came and its error where really awful, it reminded my about my time writing C where the errors from the compilers could be 50 files away from the original error. The good thing is that these improvements are not about fixing specific diagnostics, but about having a better overall system across all language
Responsive code completion is somethign else that is already being worked at. Improving code completion performance, reliability, and experience is a really important thing because is the major way a developer interacts with the langauge. Autocmpletion should show up faster than I can write, otherwise is not that much helpful.
Debugging is a real pain point. lldb is amazing, when it works. And it fails more often than not. It’s getting better, but it still has issues. I was hoping that with a more mature language, with things like ABI stability, this would have a favorable impact on this, but what do I know.
These are crucial endeavors, and they represent most engineering work that is happening in the project right now. They will remain an area of focus until these are nothing short of excellent.Ted Kremenek, On the road to Swift 6
Ted finishes this part of the post by ensuring us that developer experience is a crucial part of the work they want to focus on, and that they won’t stop the efforts until is almost excellent! This is music to my hears.
Moving to the last big theme, a theme focused more on the language itself and what is capable of.
The Core Team also wants to continue to make Swift a more powerful programming language and a better tool for solving problems.Ted Kremenek, On the road to Swift 6
I love this quote from Ted because it shows how the original vision of Swift is still intact and pushing harder than ever before!
- Round out capabilities to support expressive and elegant APIs
- Refine Swift’s to allow it to be used for low-level systems programming
- Provide excellent solutions for major language features such as memory ownership and concurrency
The first point of the theme is to keep improving the capabilities of the language to support expressive and elegant APIs. You know that this is one of my favorutie aspects of Swift, is such an expressive language that the APIs you can get with it are beautiful.
One of the best examples of this is SwiftUI with its usage of function builders and generics. But this framework also showed that the lagnauge needs more improvements around variadic generics and its DSL capabilities. So I’m glad this keeps being a major focus.
The next point is one that is often forgotten by App developers. Swift wants to shine too in low level systems programming, but right know there is some pain points that need to be fixed. The focus here is to improve Swift internal implementation to allow it to be used in constraint environments. One major aspect here is Swift’s depdency to the unicode definitions, there have been talks already exploring what would be the best way to strip that when not required.
And a really exciting point in terms of new features! I’ve been waiting for the memory ownership model for a while now, I think is one of the aspects that will set Swift apart. Being able to close some of the gap with Rust in this aspect would be amazing.
And of course the concurrency model! It’s one of the features that people makes fun of when talking about Swift, and I think that the sixth version of the language shouldn’t miss the opportunity to introduce it.
But to accomplish all these goals there should be a better organisation of the community, becuase there is so much stuff to do! So what’s the idea?
The working group model is something that has worked really well in other communities like Rust. But it Is important to understand that this are not a team of developers, but a group of people that focuses on a specific area to guide and supports the community investment and efforts.
This is something that has worked really well for Rust and fir Swift Server Working Group. It seems that the new concurrency model will have a working group, because it will need research and agreements to get into an excellent solution.
But I would love to see more investment on this structure and get even more working groups like Rust. And I think not all groups need to be technical centric. It would be great to have one for documentation, or teaching for example! How cool would it be to work on that?
By this point I know what you’re asking, so when is all of this gonna be shipped?
When it’s done!
There are NO RELEASE DATES. This efforts will take time to investigate and implement, but meanwhile we will keep having 5 point releases. The release of Swift 6 is gonna happen when those efforts culminate.
If I understand this corectly I think is a great way to make the Swift project evolve without being tied with Apple yearly releases.
- Coroutines
- Memory Ownership
- Compile Times
- Package ecosystem
- More focused and lovable community
Let’s finish with my favourites.
Of course coroutines and the concurrency model are the most exciting features that will have a great impact on our day to day coding. The majority of other language have this feature already so it is something that Swift needs to do soon. I don’t mind is taking them long because the plans they have are amazing. I’m still exciting about the technical details they shared on the concurrency manifesto. Making the async/await coroutines the building blogs instead of a higher level concept seems like a really exciting proposal.
And another feature. The memory ownership model. This one has me really excited. Right now the other language that competes with Swift in my personal love for programming is Rust. Rust was a ground breaking language for all the safety and concepts that it added to the main stream. If Swift can learn from it and bring some of those concepts, in a Swifty way, it will be more than great. I’ve been thinking about talking about what memory ownership implies, for app developers that are not deep into this low level things, but not sure how much interest this topic has. 😀
Then we get into tooling. Compile times. There is not much to say here. They need to get better, we all know that.
As I said before, I think what sets apart a language ecosystem is the quantity and quality of their packages. I don’t need Swift to have so many packages like other ecosystems, but we need more of them and keeping with the high quality standards expected.
And finally for all of this to happen I would hope to see this year a more focused community, but specially a more lovable and positivy community. I’m a little tired of seeing people argue and attack members of their own community (I mean you shouldn’t attack anybody, never, but cmon share a common love here!). Stop critising the people that dedicates time to the langauge attaching them of langauge nerds, be more open minded and for the love of god, stop confusing the Swift community for Apple. This project is a community project so you should start taking ownership of it. Rant over.
But tell me, what are you most excited about?
Our goals for Swift are ambitious: we want to make programming simple things easy, and difficult things possible.
To finish in a more, I got this quote is from Swift.org, and is what makes Swift so exciting. This clear goal, and not being conformed with the status quo is what makes this such an exciting language, ecosystem and community. Let’s keep it that way!
So this has been my video about Swift 6. I hope you enjoyed and got as excited as me with the future our beloved langauge has.