Interesting proposal though it does sound a bit too general. “Improve cross compilation”… current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy). It would be cool to expand into wasm/wasi as long as it doesn’t come at the expense of other desperately needed improvements.
Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
> current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy)
I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?
Temporary but measured in years and forced on every Swift dev out there … hard to dismiss.
My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.
Is this still a thing in Swift? I loved Swift 1, spent a couple of days upgrading to Swift 2, a week or more for Swift 3. At that point I just switched to React Native. I understand that iterating is generally a good thing, but the constant cykle breaking changes in the language was just too much.
It's now almost a full year since Swift 6 (concurrency) was introduced, and I've spent a lot of time rewriting, debugging and generally tweaking things to make the compiler happy... The promise of "strict concurrency" is yet to yield any meaningful benefit, despite the huge cost of having it.
I think the pursuit of some kind of semantic purity in the Swift language overshadows more practical needs and concerns. Making Swift too different from its neighbours like Kotlin and Rust also makes it harder to context switch. It now takes a lot more time and effort to get into the flow of developing native things for iOS...
Disagree about the academics point but Async Algorithms is basically an abandoned project at this point. There is someone working on it but the intention is that it evolves basically at the pace that the language does, but without the investment that the language gets. I would recommend against relying on anything going on there.
Between a dead Combine that no longer functions in Swift 6 or a severely handicapped AsyncSequence lacking basic features, where are developers supposed to turn to?
All these projects like Async Algorithms, AsyncExtensions, Asynchrone, etc. are being born out of necessity.
Deprecating Combine would be less of a problem if Sendable wasn’t a hard requirement but it is.
No, I'm talking about the latter. Combine is truly dead but the other repo is mired in an inability to make real changes, because that requires significant review effort, which is not really there. So it's just bugfixes and small tweaks.
Let's not forget the absurd insistence on "will change" semantics in onChange() instead of the far-more-useful notification "did change."
And of course the brain-dead design of withObservationTracking, which only fires on the FIRST change of a value. I mean... by what definition is that "tracking?" It's goddamned useless, unless of course you implement the clumsy workaround of re-establishing observation tracking every (first) time it fires.
Then there's the bizarre hypocrisy of evangelizing the "single source of truth" while telling everyone to prefer structs over classes in Swift. But structs are COPIED everywhere, which of course breaks the "single source of truth" on the first function call.
I wasted so much time trying to conform to these "best practices" until I finally realized that the people promoting them don't know WTF they're doing. Then I went back to classes, injected the "single source" everywhere it was needed, and got to work adding functionality.
And let's not even get into the half-assery that is SwiftUI... still, all these years later.
For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web.
In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms.
* Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...
I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time.
I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)
> Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support...
Can confirm. I was pretty stubborn and wanted to use Go to build a UI in a webview/webview using local app, but oh my, js.Value in Go is so much pain to deal with. A lot of things in the JS world don't integrate nicely with Go as a language (e.g. the difference of Go channels and JS Promises, or magical enum values _and_ URL patterns on the same properties like in the Fetch API)
Long story short, I am now around 3 months into building a WebASM bindings and components framework, and it's still a lot of work until I am on the functionality level of TSX files. [1] All those Web/DOM/Browser APIs are kinda hard to integrate into the Go world, especially if you're as stubborn as me and want to have a real typed bindings API that uses Go's native data types.
> It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
I mean, well, it actually already exists? It's been around for a long time and works pretty great, with multithreading, access to JS objects, etc. The author of the linked thread topic is the original author of it.
I think that’s WASI Preview 1 that’s currently supported by swiftwasm (and I don’t think the spec implementation is even complete), not the current WASI 0.2. Preview 1 was the current status quo about 2 years ago.
Writing WASM in Swift so it can only be run by a Swift runtime also misses out on a huge aspect of that “bring your language” approach to wasm. It should support enough of the spec so a current wasm binary compiled from say Go can be executed in a WASI runtime powered by Swift and vis-versa. It’s a long way to get there.
Why are they framing it as a proposal if it's done? (if this comes across as Socratic, it is unintentional, I genuinely don't understand why the author would be posting a proposal when it is done)
EDIT: My naive reading of https://github.com/swiftwasm/swift/issues is there's a lot, lot, to go. TL;DR: open from 2021, stdio FILE not available in WASILibc. Long version, filed in 2020 and open: "Pointers needed on WASILibc", "Make the toolchain work without Xcode installed", "Enable libdispatch or provide stubs for it", 2022 "canImport(Dispatch) is wrongly truthy on WASI target", "wasm lacks signal support" (broke/regression in Sept. 2024, still open)
Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.