It seems like a bit of a shame that wasm got support for exceptions but doesn't support effects which are a generalisation of the same concept.
https://wasmfx.dev/
I'm guessing this may be because exceptions exclusively require stack unwinding where as effects require full stack switching.
Thanks for that link! There goes my Saturday morning.
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.
Looking at the link, it was quite an eye-opener moment (atleast for me) to see so many language-differentiating features - exceptions, async/await, continuations, generators - can all just be abstracted into one concept called "typed continuations". I'm still wrapping my head around this.
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.
You might enjoy digging into the world of effect handlers: it's a very neat model for expressing these features and boils down to continuations in the implementation.
> We reuse WebAssembly linear memories under the covers to implement and sandbox the GC heap. A reference to a GC object is not a native pointer, it is a 32-bit index into the GC heap’s underlying linear memory [..] As far as being fast goes, it lets us use virtual-memory guard pages to elide explicit bounds checks, just like we do for linear memories
Array loads and stores still need an explicit bounds check, don't they? And struct loads and stores don't have one anyhow. Are there other bounds checks that Wasmtime is removing? I can't figure out what they mean here.
Just checked and out of the 3 major non-JS GC languages, Go and .NET aren't planning to support WASM GC due to non-matching semantics. There's an implementation for Java - TeaVM, which is an AOT Java compiler, that does have production grade support, but isn't aiming for full Java compatibility (not sure what this means in practical terms).
Native interop with JS objects on the JS GC heap isn't supported as well.
This is another good example that not all GCs are born alike, even though its is common to place them on the same basket.
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.
> Native interop with JS objects on the JS GC heap isn't supported as well.
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.
I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.
WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.
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.
> it's not running anywhere near HTML, CSS or JavaScript
There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.
It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc.
I'm not sure why people are claiming wasm isn't ready. It's just a compiler target like asm.js was. And that's been in use pretty much from the start when they got Unreal Engine, Unity, ffmpeg ported to it. Personally I've run Python + Sympy, Xcas/Giac and Maxima in the browser through this amazing tech.
Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead.
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.
There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).
NaCL was further along in every meaningful dimension (the ability to run native software at native speeds) after a year or two of development, than WASM is today after a decade (and I think this will be true a decade from now).
So the upside of WASM according to you, is that it got greenlit by the standards committee chaired by companies whose business model would've been hurt the most by a competent in-browser sandbox.
For example, the Epic-Apple Fortnite battle couldn't even have happened. Epic would've shipped it on NaCL and users would've been just as happy, and Apple (or Google) would've had no way of enforcing their sandox.
Whew, thankfully we've been saved from that terrible fate of getting to publish and enjoy software without gatekeepers and appstores.
At least I hope you have something to gain from your opinion, as the rest of us certainly lost out.
Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice.
On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that.
PNaCL was proto-WebAssembly and suffering from the same issues. They actually shipped LLVM bytecode, and you had to compile the executable locally with the whole toolchain, leading to quite bad startup performance and a lot of baggage.
Turns out there's no such thing as portable VM assembly. You still have to ship a full compiler (well, JIT) and compile the WASM IR.
Browser vendors have spent uncountable amount of engineering resources on making yet another compiler (actually multiple, since afaik Chrome uses a tiered JIT for WASM), that's neither as good as the big boys, and neither as fast as just running the dang binary.
Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.
> If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead.
Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps.
It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capability but supports streaming/local apps only, that capability is currently being developed - together with WASI layers for all of the platforms.
That way your app can run either as a browser (DOM) app, browser canvas app, native desktop or native mobile app.
It's still early, but moving fast - I just added accessibility support, and the animation framework will be out this week.
Regarding the WASM disappointed, when I started building this about 6 years ago, WASM was in a terrible (barely usable without wasting a ton of time) state. Now that WASI 0.3 is out and LLMs have sped up development by a large margin, it's in a quite usable state to ship things to production without fear.
It seems like a bit of a shame that wasm got support for exceptions but doesn't support effects which are a generalisation of the same concept. https://wasmfx.dev/
I'm guessing this may be because exceptions exclusively require stack unwinding where as effects require full stack switching.
Seems like there is still progress on that though which gives hope https://github.com/WebAssembly/stack-switching/blob/main/pro...
Thanks for that link! There goes my Saturday morning.
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%...
Looking at the link, it was quite an eye-opener moment (atleast for me) to see so many language-differentiating features - exceptions, async/await, continuations, generators - can all just be abstracted into one concept called "typed continuations". I'm still wrapping my head around this.
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.
You might enjoy digging into the world of effect handlers: it's a very neat model for expressing these features and boils down to continuations in the implementation.
PL theory seems to be in an infinite loop between arbitrary control flow like call/cc and then realizing it's hard to reason about and restricting it.
I do wish we could land on a standard model for implementing non local control flow. Like growable stacks.
> Seems like there is still progress
Oh I already know that about WASM now. All is in progress ... perpetual progress.
I'll look again in the next decade.
I would suggest you look at it a little more often than that - to improve the quality of discussion here, if for nothing else.
Wait, what does this mean?
> We reuse WebAssembly linear memories under the covers to implement and sandbox the GC heap. A reference to a GC object is not a native pointer, it is a 32-bit index into the GC heap’s underlying linear memory [..] As far as being fast goes, it lets us use virtual-memory guard pages to elide explicit bounds checks, just like we do for linear memories
Array loads and stores still need an explicit bounds check, don't they? And struct loads and stores don't have one anyhow. Are there other bounds checks that Wasmtime is removing? I can't figure out what they mean here.
Just checked and out of the 3 major non-JS GC languages, Go and .NET aren't planning to support WASM GC due to non-matching semantics. There's an implementation for Java - TeaVM, which is an AOT Java compiler, that does have production grade support, but isn't aiming for full Java compatibility (not sure what this means in practical terms).
Native interop with JS objects on the JS GC heap isn't supported as well.
Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77
What should be improved: https://github.com/dotnet/runtime/issues/94420
I'm not familiar with the current spec and those posts are from 6/3 years ago, respectively. Do you happen to know if anything has changed since?
This is another good example that not all GCs are born alike, even though its is common to place them on the same basket.
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.
> Native interop with JS objects on the JS GC heap isn't supported as well.
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.
I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.
I'm personally excited for a better thread story (not web-workers) and JIT
Does it support interior pointers?
No.
WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.
Ready for what?
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.
> it's not running anywhere near HTML, CSS or JavaScript
There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.
why.... why would financial services orgs and government infra run anything on wasm serverside?
It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc.
The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
I'm not sure why people are claiming wasm isn't ready. It's just a compiler target like asm.js was. And that's been in use pretty much from the start when they got Unreal Engine, Unity, ffmpeg ported to it. Personally I've run Python + Sympy, Xcas/Giac and Maxima in the browser through this amazing tech.
Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead.
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.
There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).
NaCL was further along in every meaningful dimension (the ability to run native software at native speeds) after a year or two of development, than WASM is today after a decade (and I think this will be true a decade from now).
So the upside of WASM according to you, is that it got greenlit by the standards committee chaired by companies whose business model would've been hurt the most by a competent in-browser sandbox.
For example, the Epic-Apple Fortnite battle couldn't even have happened. Epic would've shipped it on NaCL and users would've been just as happy, and Apple (or Google) would've had no way of enforcing their sandox.
Whew, thankfully we've been saved from that terrible fate of getting to publish and enjoy software without gatekeepers and appstores.
At least I hope you have something to gain from your opinion, as the rest of us certainly lost out.
Surely PNaCl is the one you need, because portability.
Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice.
On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that.
PNaCL was proto-WebAssembly and suffering from the same issues. They actually shipped LLVM bytecode, and you had to compile the executable locally with the whole toolchain, leading to quite bad startup performance and a lot of baggage.
Turns out there's no such thing as portable VM assembly. You still have to ship a full compiler (well, JIT) and compile the WASM IR.
Browser vendors have spent uncountable amount of engineering resources on making yet another compiler (actually multiple, since afaik Chrome uses a tiered JIT for WASM), that's neither as good as the big boys, and neither as fast as just running the dang binary.
If you make the web dependent on a CPU architecture, you're giving up on a fundamental design principle and also letting one company control it.
Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.
PNaCL was published with a standard and tooling, it was Mozzilla that refused to adopt it, and push asm.js instead.
Ironically, if it was today, Google could have pushed PNaCL without any problem.
> If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead.
Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps.
It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capability but supports streaming/local apps only, that capability is currently being developed - together with WASI layers for all of the platforms.
That way your app can run either as a browser (DOM) app, browser canvas app, native desktop or native mobile app.
It's still early, but moving fast - I just added accessibility support, and the animation framework will be out this week.
Regarding the WASM disappointed, when I started building this about 6 years ago, WASM was in a terrible (barely usable without wasting a ton of time) state. Now that WASI 0.3 is out and LLMs have sped up development by a large margin, it's in a quite usable state to ship things to production without fear.
Crediting LLMs with advancing wasm is a disservice to the best-in-industry bytecodealliance community & org.