It's just shocking to me that the compiler is asking me to help it out.
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.
Last time I converted the swift compiler from the Ubuntu package to work on Debian, stuff was looking really awry. Most things work but not simple things like sigterm signals.
Swift is a fantastic language. I think the most advanced and smart language today. And I say this having used over 20 professionally over 25 years.
Just look at how swiftUI is implemented. It's not even a DSL, it's Swift naturally! Compare it to flutter and you'll see how incredible it is. (I do like dart too though)
As for the language it's full of clever features and advanced ideas that don't suck to use and consider the developer real world use of the language.
Two things really suck in swift though; compiler error messages are straight out of the university of assholery and documentation was crafted in Mordor probably.
Of course most libraries probably won't work well on Linux yet but there is a future with the right balance between safety and speed and joy of developing.
Moving to Swift-6 mode with full data-race safety checks can be daunting. They wrote a separate post on that, and Holly telegraphed that they're still actively reducing noise, i.e., warnings where the compiler could use a bit more analysis to prove there's no race.
The really nice thing is you can use the new tooling, but stay with the 5.10 version of the language that works for your code, and feature-by-feature add Swift 6 checking. You can build the same package under both language modes, so libraries can move ahead in their versioning while still supporting clients who are not ready.
Is this shipping an entire copy of LLVM? What could possibly make this so large?
"0 matches".
Maybe on the next one.
I agree with most of the comments on this thread. The governance of the language really is a problem. You really can't run two models on the same project at once. The incentives just always get screwed up. Better to just be honest about what's going on, and then everybody can work together. But sometimes that means that people need to start getting paid, and companies love to not pay money if they can avoid it.
Also, Apple's tooling is just truly horrendous. It is just awful. I don't understand why they won't do anything about it. Xcode, there are some things that are nice about it, but compare it to really using a tool like IntelliJ IDEA well and Xcode just fails so hard.
And certain UX problems have literally persisted for a decade, and Apple has not done anything about it. It really is kind of unconscionable that Apple does this to their developers. I know on some level I am being ungrateful, because there are mountains being moved behind the scenes by Xcode, and I really do appreciate that. And from watching WWDC talks, I know that there are some really good engineers at Apple that are trying to do the right thing. And some of it is just corporate BS that is unavoidable. But they really do need to get better.
In any case, I hope that this update makes everybody's life better. When it is really nice, I think that Swift has some of the best developer ergonomics out there. That's just one person's opinion, of course.
[1] See e.g. https://literatejava.com/exceptions/checked-exceptions-javas..., but also Java 8+ API's moving away from them.
https://hachyderm.io/@evanw/109859384302551859
https://www.cocoawithlove.com/blog/2016/07/12/type-checker-i...
https://danielchasehooper.com/posts/why-swift-is-slow/
This isn't mentioned at all in the announcement so I'm kind of disappointed.
I’d be interested to know how good this integration is in practice e.g. could it be used to integrate with Godot directly?
Swift is caught between two clans: the Swift Working Group™ open-source community, and the Apple corporate entity who pays most of their salaries. Both have their own incentives and their own imperfections, but you guess who has the majority influence.
Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase. Even worse, half-baked concepts such as result builders are pushed through without any real discussion because Apple wants the SwiftUI syntax to look pretty.
It's an amazing language still, but I can't see it surviving as nicely in the next 10 years if Apple doesn't learn to let go.