Hacker News Reader

Comment by apitman | Hacker News Reader

I started using WebAssembly in earnest a few months ago to make a backend auth library that works in several different languages[0]. It's built on Extism[1], which abstracts away some of the interfacing complexity. It's been an awesome experience. Frequently feels like magic.

WASM is in an interesting place. The value has clearly been proved with a pretty minimal core spec. Now there's a big push to implement a much larger API surface for WASI and the Component Model. A lot of people in the community are concerned about this direction, or at least the way it's happening[2].

For my part, I hope WASM doesn't go the way of the rest of web browsers where it gets so complicated that only big tech is capable of making implementations and experimenting.

[0]: https://github.com/lastlogin-net/decent-auth

[1]: https://extism.org/

[2]: https://www.assemblyscript.org/standards-objections.html

View on HN

I agree about what your concerns about complexity, but the way I see what we're encapsulating is almost entirely essential. To draw analogies with native binaries:

- Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).

- Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).

- WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).

To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.

> A standard instruction set, standard calling convention, and standard syscalls.

This sounds like an OS like user space to run atop WASM similar to POSIX.

Standards are good but my hope is the design is well thought out.

I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?

Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers.

I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.

> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation?

The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.

Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.

[1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md

So basically the reasoning is that things like wasi-http wouldn't be mandatory for a compliant implementation? That would be good.

Thanks for the link. I was trying to find a single page with everything listed.

>The question is how likely is the current tragectory to follow what happened with browsers?

What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine?

And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime).

>The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?

Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences.

At least with an official spec implementations will be compatible, and we'll get some reference one.

I think it makes a lot of sense to have a standard HTTP interface. I mean, HTTP is well defined and the interface matches the spec pretty closely. Allowing implementers to use whatever underlying protocols is sensible, specially in cloud environments.

You can also have a standard web assembly component that simply implements wasi-http on top of wasi-sockets.

One of the maintainers of Extism here! Thank you for the kind words.

As you know, we're all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some "maybe in the future" standard a la Components.

If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we're in it for the long haul.

For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion & serialization across the guest-host boundary, worth checking out: https://github.com/dylibso/xtp-bindgen

Thank you for Exstism. My main request is that you keep the core interface as simple and forkable as is feasible. You're certainly incentivized to make it as complicated as possible so only your team can maintain it, but I hope you're able to find a sustainable business model that doesn't go down that path.

I wouldn’t say incentivized, but temptation would lead to that. We are not tempted though. We build new things on the same open, simple interfaces we want to support long term.

For example, https://mcp.run is one such business we are very excited about — and it is Extism at the core. No modifications to the runtime, just the same Extism we all know and love.

And we want way more than our own team to help maintain the open source project, no doubt about that! So simplicity and transparency are the name of the game.

I'd love to hear why WASM now has more promise than Java 1.x.

Java's subsequent development was driven by enterprise/containers (mainly Oracle), and the VM has stayed relevant for 30 years by incorporating dozens of advances in machine and programming models. Both successful and lamentable.

If WASM (i.e., the loose collection of organizations driving it) could do it better than Java, wouldn't Java (with all its resources and organization) have already done it?

The answer has to lie in unsustainable or limiting technical decisions. What exactly are the design decisions WASM made to make it seem like it would escape becoming Java-like?

Roughly the same reason as every time someone asks the same question in any post that mentions WASM: Java is a particular model with a particular view of the world, tied to a GC and a particular standard library and various hard limitations such as no user-defined value types that make it impossible to compile C code to properly and run it with reasonably C-like speed. Just because Java has incorporated dozens of 'advances' doesn't mean any of them address its longstanding problems, and you're mixing implementation tech with spec design in your reasoning. You, in your daily life, likely use zero software incorporating Java and multiple pieces of software incorporating WASM. You cannot imagine using Java for shaping functions embedded in font files, or sandboxed 'native' modules in a JS-based text editor, or blockchain smart contracts. In fact Java basically cannot be reliably sandboxed at all.

Because WASM is currently solving a real problem for me that Java can't solve, ie easily embedding code I wrote in one language into many other languages. You can do something similar with shared libraries, but you have to compile them for every architecture and OS and solve the associated distribution problems. Ask Python and JS how that works out in practice. A WASM artifact runs everywhere, and has addition security benefits.

It will be re-inventing the whole application containers ecosystems we had back a few decades ago across JVM and CLR ecosystems.

When you jump into every WASM thread with this take, what are you trying to accomplish?

Make everyone aware, born after 2000's what is being re-invented, while being sold as innovative.

You are free to ignore my comments.

That's a fair reason. It's important to realize how often we re-invent the wheel in our field. As an example, you're an expert in distributed systems, which I've only recently started dabbling in. In the process I'm learning how so many of the fancy "new" distributed systems and we have today were essentially invented decades ago.

But in the WASM case, to what end? There's a cost to your comments. I'm sharing an example of how WASM has helped me solve a real problem, and might solve real problems for other people. Your comments create noise to these types of discussions.

Maybe it's worth the tradeoff in your mind, but I'm curious what your end goal is?

I can't speak to his purpose but for myself I find it interesting to consider the differences that lead WASM to help you solve a real problem where the preexisting solutions presumably didn't.

WASM is designed to be embedded and its model is that of native code rather than any particular high-level language's primitives. It is closer to LLVM than Java. Comparisons to Java are surface-level and boring, since all foundational reasons why Java failed are false of WASM.

Interestingly enough, people keep forgetting that since UNCOL in 1958 there were many polyglot bytecode based runtimes, because comparing to Java is always easier argument.

You're the one who brought it up. Make a good point or don't.

Believe it or not, just because on an abstract technically something similar has been done before, its possible for people to still care about something that is being built. Reinventing the wheel is perfectly fine and even good, special if it happens in a different context and with a different community and process. And the WebAssembly people are well aware that Java/CLI exist and are learning from it.

Making the same comment on every single Webassembly thread for the last couple years as if the everybody working on WebAssembly or WASI is some bro-programer born in 2008 is just disrespectful to the engineers working on these projects.

Sorry that we are not all as cool as you and use UNCOL everyday. I mean who would want to use a technical idea that isn't first of its kind.

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.

And in a couple of years the same will most likely happen to the WASM backend.

That was already possible with Haskell to JavaScript.

For all browser targets to die, people must no longer be interested in writing Haskell while writing webapps, even though people will probably remain interested in writing Haskell, and probably remain writing webapps, which seems unlikely. For the WASM target to die and the JS target to remain, this would have to mean that there is some technical barrier that makes the maintenance burden not worth the staggering performance gain, and if there is some such burden I am not aware of it. 'Java died so WASM will die because both are VMs' is basically a content-free dismissal - what do you actually think will no longer be needed, or is currently not needed but overvalued, and why?

Yet we are talking about targeting the server in this thread, because so far the tooling for the browser sucks, and VCs are more willing to sponsor startups selling server products.

Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.

I am comparing your words about WASM to your words about JS. Misdirections about VCs are irrelevant. You can expect the WASM target to have as great or greater longevity than the JS target, and if your prediction about future failure isn't true of JS then it won't be true of WASM.

WASM on the server isn't the same as JS on the browser.

And that surely has something to do with the price of tea in China. WASM on the client is why you mentioned JS.

Also we have suffered a couple decades of JavaScript to give us that little extra motivation to make a common runtime environment work. And WASM is open source and thus not proprietary. And all the browsers (well, really, the one browser) are open source. The FOSS community is much more robust than it was 30 years ago, and there are many times more professional software devs floating around too, and security tooling and practices are substantially better now. Personally though I think the general antipathy for JavaScript and its endless parade of duplicative over hyped frameworks alone would suffice to push WASM forward.

And yet, most of the efforts are geared towards using it outside of the browser, where better alternatives to JavaScript have always been available.

Reply on news.ycombinator.com