Swift 6 is the first version with enough low-level improvements and cross-platform capabilities to make me curious if the Swift team is trying to aim for long-term replacing C, C++, Rust, Zig, etc.
I don't get how people still get surprised by this.
I haven’t given 6.0 a full effort yet, but a couple test compiles without any tuning showed only incremental improvements.
O'Leary's Law of Swift Comments on HN, much like Betteridge's Law of Headlines, says the answer to Swift speculation on HN is always no.
If there is any global aim, it is to migrate internal teams still working in ObjC/C++ to Swift.
If this sounds close-minded, it's worth talking with an iOS developer 1:1 and get info on the day-to-day experience of SwiftUI 5 years in, and concurrency/actors 3 years in. They have a lot of fires to fight to keep the house standing.
Apple's stated goal is to make Swift a viable language up and down the technology stack, which goes way beyond Objective-C. They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. IIRC they even referred to it as a C++ successor language at WWDC this year.
I agree that they're not trying to "replacing every other programming language," but they're investing in it becoming a viable language choice in most environments.
Nice!
I'd gently warn against parsing that too closely: having been in the community and the weeds starting in 2014(!).
ex. the cross platform Foundation was announced and open sourced in 2016.
I'm sure a lot of things were upgraded or more consistent and its better etc., but it's a painful to remember what was expected + communicated at the time, and how much later it is.
I don’t think Swift has a place in these niches FWIW. Writing low-level Swift code is very verbose and unnatural. Personally I just don’t think it’s practical to have a single language excel across the stack.
Right now, my Mac app depends on a few simple web services that are written in a different language. It would be neat if those services could be written in Swift, so that I could just use the language I already know instead of relearning how to do decode JSON in Python/Ruby/PHP.
Swift on the server doesn't have to become widely used. As long as there is a simple way to write basic web services, it is useful.
Then somebody else would have to now learn Swift even thought they write in different language like: Android Developers (Kotlin/Java), React Native devs (JS/TS ), Windows Devs, Linux Devs etc. As long as Apple don't invest more in official cross-platform tooling Swift is not gonna be mainstream (even though I like Swift). They have to bless other competing platforms.
If you have a bigger team, then it doesn't matter as much, because you have different people who do the iOS app, people who do the website, people who do the back end etc.
Swift on the server doesn't have to go mainstream to be useful. If you just need some basic web service that syncs highscores or verifies in-app purchases then it would be neat if you could write that in the same language as the app itself.
Selfishly I wish mixed C targets were a priority before C++ but I get why this was more important to them
Objective-C was in the kernel.
Objective-C requires a runtime. I thought the kernel was always C/C++.
On NeXTStep / OPENSTEP kernel drivers could be and were written in Objective-C.
https://www.nextcomputers.org/files/manuals/nd/OperatingSyst...
It was in NeXTSTEP. It was taken out because of performance concerns that turned out to be entirely unfounded. Alas, when they figured out that this was the case it was too late.
A similar example is CoreFoundation. It was a C implementation of the OPENSTEP Foundation. To this day, even really smart, capable and knowledgeable engineers believe that CoreFoundation is faster than the pure Objective-C Foundation. It is not. It is significantly slower. Often several times slower.
(It is of course very slightly faster than the "new" Objective-C Foundation that was implemented on top of CoreFoundation).
Another example is Swift. People believe it to be generally faster than Objective-C. Again, this is not the case. Swift code tends to be significantly slower than comparable Objective-C code.
The runtime support that's required for Objective-C is extremely minimal. In the end you need objc_msgSend() and some runtime structures so that function works.
The methods themselves are just C functions with slightly funky names.
It’s already been used in their libraries, their OSes, and even firmware on embedded processors.
This is the way forward. And they’re dogfooding it. Even in some of their embedded processors.
To me it kind of feels like swift's place here is going to replace the subset of c++ that apple is mostly interested in. But not necessarily the c++ that they aren't and then likely not the c++ that rust et al are able to replace (although I guess we'll see what they have in mind as time goes by).
I suspect they'll be disappointed if they try to replace c++ in totality. As the end result will likely not be particularly habitable.
Why is that? That is their aim, I think they’ve made it clear.
They’re writing all-ish new code in Swift (not always practical in existing code) from what I understand. They’re already using it for the code that runs in places like the Secure Enclave or other embedded processors.
Can it replace C++ 100% everywhere today? Probably not. I don’t know enough to know why. But that absolutely appears to be the goal.
People keep doing that, because I guess they hatred for Java and Kotlin is higher than the pain of using NDK.
Kotlin’s real strength is the compilers ability to target as many different backends as you want and cross compile into any platform you want. I have an app in production that save for about three lines of swift that declares the view controller for iOS specifically, shares its entire codebase all in kotlin between Android, iOS, Mac, Linux, and Windows. I could add a line to the build file and add web as a target and turn it into a web app.
I feel like “systems programming” is getting increasingly ill-defined these days, anyway. If Kotlin and Java aren’t allowed, how about Go? Are you ruling out all languages with garbage collection?
Currently that’s C, Rust, and some assembly.. obviously there are more languages used for systems programming tasks too. Memory management, concurrency, and low-level access are also super important in a system language. How would you define a systems language?
It doesn't really need to mention "systems" specifically, since the comparison to other common systems languages, in addition to the words "low-level" implicitly imply systems programming languages.
Usually, languages with GC will not be considered contenders for systems programming.
On the more minor side of things, Swift's built in JSON serialization is super handy. It's really nice to not have to increment the dependency counter to parse JSON and makes spinning up projects that much faster.
Kotlin is nowhere close to Java in this comparison. For all intents, there is just one realistic IDE for Kotlin. And realistically only one build system. And the community is very small. Java, by comparison, has many IDEs to choose from, many build systems, and a very large community to answer questions.
K
I've been using C#/.Net lately and I've been very impressed. Very large ecosystem and community. Perhaps larger than Kotlin. And you are not stuck with one IDE from one company.
Microsoft also has dotnet MAUI that sounds similar to Compose Multiplatform. I have not used neither so I can't speak to any strengths or weaknesses in the UI libraries.
I’m amazed people like C# so much. I think it really shows its age when you compare it to Swift or another modern language.
Some things I’ve been frustrated with:
- throwing isn’t a contract made at the function level. Anything can throw, and you can ignore it if you want. And the APIs are inconsistent because of it
- nullable types and default values are weird and seem like two solutions to the same problem
- Blazor bindings are very boilerplate heavy
- hot reload doesn’t work most of the time, and iteration times are bad compared to every other stack I’ve used