> Which will always be the best DX for writing code in the browser.
The article we're all commenting on is not about running WASM in the browser.
WASI in particular may never be supported by browsers.
The article we're all commenting on is not about running WASM in the browser.
WASI in particular may never be supported by browsers.
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.
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...
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.
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.
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.
Right.
> 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.
Things like JVM and .NET are great, but not designed to be embedded other languages.
- 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.
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.
It is used used by projects like Postgres PL/Java, LibreOffice and various native Java launchers/wrappers