swift-5.3-RELEASE (downloaded/installed from swift.org) to /Library/Developer/Toolchains
swift-tensorflow-RELEASE-0.8 in /Library/Developer/Toolchains
My gripe is that I have both 1 and 2. Of course, I'm aware I can get rid of 2 and use 1 for the command line. But if my Swift IDE of choice were VSCode (I point to this tweet), it somehow feels wrong that I'm telling VSCode to use a toolchain embedded within another IDE. I just don't like how opinionated Swift is about it's IDE. I get similar chills about Kotlin's preference for JetBrains IDEs, etc. IMO, a language should be agnostic about the IDE the user chooses... let the user pick. SourceKit is one good step in the right direction on this matter.
(Don't get me wrong... I like Xcode as an IDE, and still think it gives the best Swift experience. I may continue to use it for Swift in any case. But it won't be everyone's choice.)
So, in some sense, what I'm asking for, is that when Xcode is installed/upgraded, it downloads the latest toolchain and installs it to /Library/Developer/Toolchains (neutral) place for all IDEs (including itself) to point to. It sounds like the embedded one may be "customized and proprietary" vs. the one downloaded from swift.org, but it at least could store it in /Library/Developer/Toolchains where it's more accessible.
Forgive me the interjection, WebAssembly is not a subset of JavaScript in any way, nor it is related to JavaScript. There are multiple WebAssembly hosts available outside browsers, not including Node.js, and most of them don't have direct support for JavaScript whatsoever.
SwiftWasm (one word, "Wasm" doesn't require all-caps as an abbreviation, not an acronym, see the spec) does support any of those hosts as long as they provide support for WASI. While JavaScript polyfills exist for browsers, hosts such as Wasmer implement WASI w/o any involvement from JavaScript.
In other words, right now you can run SwiftWasm apps on any Wasm host as long as they support WASI in some form (all browsers do with a polyfill that you get via carton). JavaScript support/integration is not required for SwiftWasm, nor it is related to non-browser Wasm hosts, other than Node.js.
We do have plans to get rid of the WASI dependency to make SwiftWasm apps even more portable, but that will take some time.
I see. Thanks for stopping the spread of misinformation that I unleashed. There was a proposal to standardize on a subset of JavaScript as compile target for higher-level languages. But that was asm.js. WebAssembly was born out of that idea.
In any case, I think Wasm will be huge for Swift. Web development it a huge and important platform and Wasm is Swift's ticket in. So, I think it's fair to say Wasm may be a really big part of Swift's future and world domination scheme.
I think the biggest Wasm challenge is getting a cohesive front-end development experience. Stuff like JavaScriptKit is a great start. But eventually, it would be nice to develop in Wasm in 100% pure Swift without even having to remember that JS exists.
On the Rust side, Yew is a valiant effort, though is a bit clunky in places with a bit too much boilerplate (compared to React)... but it's nice to see that it's possible to write a web app without a line of JS. Yew does add some transpiled JS to get a few things going, but the UI is pretty much running JS-free. I did a test trial of it a month or two back: Yew Test
For Swift, it's tempting to think we can have "SwiftUI for the web", though I'm skeptical (since there is no clear evidence SwiftUI will go open source anytime soon and building native UI is inherently different than web UI). Projects like SwiftWebUI look really cool... but are still toys and not suitable for actual production.
Anyway, lots of promising stuff... but getting all parts aligned into a cohesive experience will still be a challenge. If we can do so, Swift will rule Wasm and rule the web!
SwiftUI compatibility in Tokamak is one of the major projects that the SwiftWasm team is working on, and its goal is to be suitable in production and to eventually support as many platforms as possible, not just browsers. I'm not aware of anyone using it in production yet, but if anyone's interested, let me know what exactly do you find lacking for your use case and we'll prioritise it accordingly.
Our team at Google cares very much about performance, and so we've developed GitHub - google/swift-benchmark: A swift library to benchmark code snippets.. Although we still need CLI integration, it's hopefully a valuable contribution in this direction. The functionality therein has been meeting our needs for a few months now, and we're close to a first release. Feedback (and PRs) welcome!
Have there been any plans to tag at least one release of swift-benchmark? I would love to use it in many projects, but the lack of tagged releases makes it a non-starter. I've asked about it on GitHub, but there were no updates at all on that.
Sorry about that! We intend to get a tagged release soon. (We've been somewhat distracted by some academic paper deadlines, but these fortunately are time-bounded operations. Sorry about the delay!)