After a bunch of middle clicking I landed here [0]. So if I understand correctly, the current stack switching proposal depended on exception handling to be implemented first for resume.throw, so that bit was blocked until now.

But it's also further along than you might assume [1], i.e. you can already invoke Wasmtime with `-W stack-switching` and hit the boundaries where the experimental implementation breaks.

Sadly though, like many ambitious Wasm things that don't have revenue directly attached to them, it now seems partly a case of finding someone willing to sponsor or finish the remaining work [2].

I also found the list of open stack-switching issues[3] useful.

(also, minor nit - Wasm != Wasmtime)

[0]: https://github.com/bytecodealliance/wasmtime/issues/10248

[1]: https://github.com/bytecodealliance/wasmtime/issues/12941

[2]: https://github.com/bytecodealliance/wasmtime/issues/12941#is...

[3]: https://github.com/bytecodealliance/wasmtime/issues?q=state%...

On one hand, I'd assume a "focused" feature, like exceptions, would always be easier to fine-tune and optimize the language, runtime and workflow – rather than generalizing it.

But at the same time, the prospect of saying all those are just special forms of a stacked "yield" (just for my mental model) is quite tantalizing.

Oh I already know that about WASM now. All is in progress ... perpetual progress.

I'll look again in the next decade.

What should be improved: https://github.com/dotnet/runtime/issues/94420

WASM GC is a MVP, only usable by languages whose GC requirements overlap with JavaScript's GC.

Java has it easier than either Go or C#, because the Java and JVM specification is actually silent on how GC should be implemented, hence why there are so many implementations to chose from across JVMs.

Outside the browser there is hardly any value, just use JVM or CLR directly.

Isn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.

WASM is already running in production at a whole bunch of financial services orgs and government infra.

The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.

Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner.

I guess WASM turned out to be a sandbagging rather than sandboxing technology.

But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.