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”.
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?
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.
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...
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.
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.
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)
https://bootsharp.com/guide/llvm / https://github.com/elringus/bootsharp
While Apple has been big on pushing multi-platform Swift right now and distancing itself a bit from the Swift branding in some ways (e.g. it having its own GitHub organization) they've historically had quite an ebb and flow to this behavior. If their priorities changed, what happens to the non-Apple projects that adopted Swift? It would be better if there were multiple parties that had stake and some control in the future of Swift.
I have similar worries with Microsoft and .NET, although it's a bit different owing to the fact that Microsoft is quite a different company with different problems.
It's actually kind of bizarre that it never really felt like Google was a problem for Go, but I guess that's because unlike Apple Swift and Microsoft .NET, Go mostly targets and is almost entirely developed on platforms that Google has little control over. (Though that doesn't mean that their presence is entirely unnoticed, but even stuff like the module proxy has been more well-received than expected. It's an odd area where Google has managed to maintain some goodwill, though it could evaporate over night.)
[0]: https://www.swift.org/getting-started/embedded-swift/Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on.
Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.
It makes print-statement debugging look cutting edge.
For me, SwiftUI does exactly two things better than UIKit: tables and collection views. For everything else, it's so much easier to get stuff done with UIKit*, regardless of if I'm working with Interface Builder or making UI in code (as per various projects I've dropped into).
In theory, reactive UI is good. In practice, at least in the case of SwiftUI, the "magic" data passing does sometimes fail — perhaps someone put in the wrong @ on the property — and then you've got to debug some weird magic, and if there's a sensible place to put a breakpoint for that kind of problem I have yet to learn it.
In theory, the UI is reusable across all Apple platforms. In practice, the nature of the user experience is so different that actually trying this makes it suck for everyone — you don't want finger-sized buttons on a mouse-driven UI or tiny mouse-suitable click areas for a mobile UI, and I have no idea what the user expectations are for tvOS or WatchOS despite having written apps for both because hardly anyone shares their experiences and lessons learned.
In theory, having the code be the source of truth for the WYSIWYG editor is great. In practice, the WYSIWYG editor keeps giving up because of e.g. a compiler error, and decides to stop forever until you manually resume the preview.
* I'm mostly on iOS rather than macOS, but I'd assume UIKit and AppKit have the same strengths and weaknesses.
And so I write pure code UIKit most of the time. It’s not trendy but it’s very effective.
How would UIs work on other platforms, though?
I think for right now, you'd have to use the C interop and link against something like GTK or other GUI library. I don't think SwiftUI specifically would ever work well cross-platform, it has so many Apple-isms.
There's also Swift/Win32, but it's MVC. You could also use the interop and use QT as well.
I don't think any of those are necessarily good solutions, but they are there.
There’s stuff like SwiftCrossUI that does multiple backend bindings
https://github.com/stackotter/swift-cross-ui
And Qt was exploring some bindings using the new C++ interoperability.
Sure, if you are on Apple devices. If you are not, better to use other languages like Rust, Go, or even Dart.
#!/usr/bin/env swift
It's basically a drop-in replacement:
#/path/to/autocompile_or_interpret_swift
real 0m0.212s user 0m0.159s sys 0m0.045s
vs
real 0m0.014s user 0m0.004s sys 0m0.008s [0]: https://github.com/apple/swift-argument-parserAnd for no real reason, except that apparently Apple's whole ecosystem can crash and burn if somebody looks at it wrongly.
This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.