> I'm aware of the article's context but that just raises further questions. Why invest much effort, as a developer, or as a vendor, in a version of WASM that doesn't even let you run client side? It's carving an ever smaller niche.
Because of the value it can deliver server-side, and that's where most of the value tends to be.
Server-side compute is the core of most companies' revenue streams, yet it really is bloating out of control. Think about how much money is wasted on build pipelines, artifact storage, giant image distribution, multi-tenant workload isolation, supply chain risk mitigation; how expensive cloud infrastructure is, and what a substantial share of it is spent on all of those. With the way WASM was designed, it has the potential to completely upend all of it: tiny binaries, sandboxed runtimes, tightly knit mt, instant scaling, clearly defined contracts, language agnostic microservices. It's a completely different world.
The potential for WASM in enterprise compute is immense - especially with the recent developments in the component model and WASI. We're talking about orders of magnitude improvements here.
Do those "more mature" options support architecture-independent executables written in Rust or Go, so that a company doesn't need to rewrite their existing code in Java?
Containers are a much heavier way to implement a plug-in system, since you will also need to define an RPC of some kind, and they're not architecture-independent unless you require the users to build every container for every architecture. Containers generally aren't a security boundary, but you can wrap them in something like firecracker to help with that. (I believe plugins were an essential part of the context, based on the post we're commenting on, so it is important to evaluate these options against that.)
LLVM IR as it is actually generated is also not architecture independent, and not a security boundary, making it a poor way to do a plugin system. Definitely not more mature for this type of stuff.
.NET MSIL is probably a better fit than the other two options you provided, but not a good one... I don't think Go or Rust compile to MSIL, and MSIL probably isn't a very good security boundary anyways.
I know from past discussions that you don't like WASM. I think you're overly dismissive of it. WASM has been around long enough now that it is a fairly mature system. I haven't personally needed it, but that's simply a comment on my own work experience, not the usefulness of the technology for specific use cases... and I can easily see why people are passionate about WASM. It's not NIH syndrome.
If you want a plugin-in system, maybe don't pick a language with static linking, and an half-backed plugin implementation in first place.
WebAssembly outside of the browser is a solution looking for a problem that has been sorted out multiple times since the idea of bytecode based execution exist, 1958 to be more precise.
Even on the browser its use, besides bringing back the old plugins is debatable, using GPU compute is much better for number crunching, with much better tooling.
Yes… I’m aware of the history. I’m also aware that WASM solves problems that those previous ones didn’t. Otherwise you would have provided an option that actually met the requirements, if there are so many to choose from.
> If you want a plugin-in system, maybe don't pick a language with static linking
Or… a plugin system could “just work”, without placing unnecessary restrictions on what I do.
The right language for a plugin system is the one that attracts the most plugin writers. Supporting many languages is a huge boon for wasm in this department. It's one of the things that makes the JVM and .NET so appealing in the first place, but WASM is better than both combined when it comes to language selection.
It is very popular in gamedev space whenever using C# as a high-performance scripting language.
You are right to say this is low-level though, but low-level scenarios are not as niche for .NET platform as they are for other languages in this category.
The article we're all commenting on is not about running WASM in the browser.
WASI in particular may never be supported by browsers.