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.

> 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.

Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.

They could call it wRPC or something

Funnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/).

For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...

And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.

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?

Well, depends if they target LLVM IR, or .NET MSIL.

https://www.graalvm.org/latest/reference-manual/llvm/

https://github.com/FractalFir/rustc_codegen_clr

Also ever heard about containers?

They have this magic feature, you don't need to rewrite anything to run on servers.

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.

It starts by choosing the right language for the job.

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.

That surely isn't any WebAssembly then, if we are counting adoption growth throughout computing history.

How do I prevent my statically linked plugins from having any filesystem access, or a bug messing with memory it doesn’t control once it’s loaded?

OS IPC and security configuration, no need to add a WebAssembly runtime and compiler toolchain.

So: slow, hard, complex and highly OS specific vs simple and secure.

Right.

Because WASM tooling is so much better, thank goodness for emscripten.

Don’t argue in bad faith, especially if you’ve got nothing substantial to add to the discussion or any real points to make.

I'm not aware of any tech other than wasm that I could be using to implement decent-auth: https://github.com/lastlogin-net/decent-auth

Things like JVM and .NET are great, but not designed to be embedded other languages.

Dynamic libraries come to mind.

You have to recompile for every architecture and OS, and no security features.

.NET does support embedding:

- As full runtime i.e. hostfxr https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc... (supplementary: https://github.com/StudioCherno/Coral)

- As a dynamic library via DNNE with full runtime: https://github.com/AaronRobinsonMSFT/DNNE

- As either dynamic (easy) or static (hard) native library: https://github.com/dotnet/samples/tree/main/core/nativeaot/N...

There are a few community projects which build on top of these to provide a more seamless integration with other languages.

That's actually really cool, thanks for sharing. Does seem pretty low level and niche though.

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.

You can embed JVM with JNI_CreateJavaVM(): https://docs.oracle.com/javase/7/docs/technotes/guides/jni/s...

It is used used by projects like Postgres PL/Java, LibreOffice and various native Java launchers/wrappers