WASM threads have been supported in every browser since 2021, but Rust can't support them because production users and library authors enabled WASM support in thread-unsafe ways relying on WASM being single threaded, so enabling it would almost certainly introduce vulnerabilities.

That's sad. You can always upgrade to a different language! :) Yh, wasm. I also very stoked for the tech. But actually, what are good use cases? I'm very impressed by openttd in browser and Autocad. What do you think wasm will bring us?

Not all is lost though, there will probably be a different WASM target with native threading support. I look forward to the third WASM target that will use WASI threading.

@whimsical I look forward the most to the end of Javascript's hegemony and opening the floor to languages with better static analysis and opportunistic parallelization potential, although that may be a bit ambitious. Otherwise, I hope it can become a democratic distribution method for indie games. Since payment providers like Stripe aren't too difficult, the biggest argument in favour of Steam for many devs is actually player convenience.

That's not the end of the threading issues either. You need special cors rules on the server as well, that prevent you from having 3rd party links. It's something @whimsical and I bumped into

@BordedDev soon we have such a sick and amazing platform 😁

@BordedDev what has cors got to do with the parallelization of client-side programs?

@lorentz "security" it allowed a specter exploit because of an exploit in shared memory (I don't know why this required, instead of just allowing us the same postMessage interface - maybe don't call it a thread then but still a threading setup with the isolation burden would be appreciated) so now you have to have cross-origin isolation.

This has bit more of a write up: https://web.dev/articles/...

@BordedDev That's odd, I could've sworn that Rust's wasm support uses a virtual stack to allow "blocking" the "invoking thread" which all looks like regular async work from the JS side. I mean, Rust at least actually has a type of async support that makes no assumptions about the executor so you can use that. But still, it surprises me that the general solution isn't to lift all work into promises while we're already on a compilation boundary where anything goes.

What the hell is going in with WASM in general. It has been in development for like 10 years and its still like 0.1 alpha. Reference types are still experimental, theres no garbage collector support, no dom access, etc. etc.

Like do they actually want to finish it at some point...?

@12bitfloat I'm not sure why the narrative is that it's a dev version, but I'm like 95% sure that the current feature set is permanent and will only ever be deprecated, not removed, as is usually the case with stable web APIs. The solution for bindings seems to be mostly to write very specific JS glue distributed alongside compilers like Emscripten that the browser can trace compile. Cooperative GC is an unbelievably hard problem, and switching between WASM and arbitrary (uncompiled or dynamically typed) JS is pretty slow, so I don't expect we'll get many features to encourage using them together.

@lorentz Oh no, I don't expect them to remove features already implemented and used in browsers

That's probably one reason they take so long to design; they don't want to specify something that sucks

Still, it does seem unreasonably long for some pretty basic features (maybe minus GC, that one I can see being a real pain in the ass to design)