5 ms·

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access. The browser is the main driving force for WASM, as I see it, because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container. So WASM doesn't really have much impetus to improve beyond compute.

boomskats 1y ago
> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're implying here. > The browser is the main driving force for WASM, as I see it This hasn't been the case for a while. In your first paragraph you yourself say that 'the people furthering WASM are [...] building a whole new VM ecosystem that the browser people aren't interested in' - if that's the case, how can the browser be the main driving force for Wasm? It's true, though, that there's verey little revenue in browser-based Wasm. There is revenue in enterprise compute. > because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container Not exactly true when you consider that docker containers are orders of magnitude bigger, slower to mirror and start up, require architecture specific binaries, are not great at actually 'containing' fallout from insecure code, supply chain vulns, etc.. The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. They just rarely make it to the hn frontpage, because they really are boring. However, the Wasm push in enterprise compute is real, and the value is real. But you're right that the ecosystem and its sponsorship is still struggling - in some part due to lack of support for the component model by the browser people. The component model support introduced in go 1.25 has been huge though, at least for the (imho bigger) enterprise compute use case, and the upcoming update to the component model (wasi p3) should make a ton of this stuff way more usable. So it's a really interesting time for Wasm.
- serbuvlad 1y ago
  > The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. What are you talking about? Alpine container image is <5MB. Debian container image (if you really need glibc) is 30MB. wasmtime is 50MB. If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too. Also, Docker images get overlayed. So if I have many Go or Rust apps running on Alpine or Debian as simple static binaries, the 5MB/30MB base system only exists once. (Same as a wasmtime binary running multiple programs).
  - rkangel 1y ago
    These numbers are true, but you'd be amazed and the number of organisations that have containers that are just based on ubuntu:latest, and don't strip package cache etc.
    - nightpool 1y ago
      Surely moving those containers to alpine would be 1000x easier than rewriting everything in wasm though.
    - serbuvlad 1y ago
      ubuntu:latest is also 30MB, like Debian. Obviously an unoptimized C++/Python stack that depends on a billion .so's (specific versions only) and pip packages is going to waste space. The advantage of containers for these apps is that it can "contain" the problem, without having to rewrite them. The "modern" languages: Go and Rust produce apps that depend either only on glibc (Rust) or on nothing at all (Rust w/ musl and Go). You can plop these binaries on any Linux system and they will "just work" (provided the kernel isn't ancient). Sure, the binaries can be fat, but it's a few dozen megabytes at the worst. This is not an issue as long as you architect around it (prefer busybox-style everything-in-a-binary to coreutils-style many-binaries). Moreover, a VM isn't much necessary, as these programming languages can be easily cross-compiled (especially Go, for which I have the most experience). Compared to C/C++ where cross-compiling is a massive pain which led to Java and it's VM dominating because it made cross-compilation unnecessary, I can run `GOOS=windows GOARCH=arm64 go build` and build a native windows arm64 binary from x86-64 Linux with nothing but the standard Go compiler. The advantage of containers for Rust and Go lies in orchestration and separation of filesystem, user, ipc etc. namespaces. Especially orchestration in a distributed (cluster) environment. These containers need nothing more than the Alpine environment, configs, static data and the binary to run. I fail to see what problem WASM is trying to solve in this space.
pjmlp 1y ago
Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.
- mananaysiempre 1y ago
  Already-established single-vendor VM ecosystems.
  - pjmlp 1y ago
    On the contrary, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.wikipedia.org/wiki/List_of_Java_virtual_machines And looking at other bytecode based systems, enough runtimes with multiple vendors. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode
    - mananaysiempre 1y ago
      I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of guys in a room in 1997 and last had a feature added to it in 2000. So I can’t help observing the non-obsolete JVMs not targeting an embedded usecase (and thus capable of supporting the kind of tools you’re referring to) are all either research projects or OpenJDK-based (or both). Harmony is dead. GCJ is dead. (Does Dalvik count?..) Oracle has already perpetrated half of a rugpull on OpenJDK and mostly murdered the JCP, and that ratchet only ever goes in one direction. And the tooling of the kind you describe is mostly sold by a handful of companies for a handful of notable languages, none of which were born outside the JVM context: Kotlin is the last entrant there, and it is very good, but the tooling is also very distinctly a single-vendor thing to the point that Google didn’t roll their own. (Both Clojure and Scala are lovely, but I don’t think they’re on the same side of notable as Java or Kotlin. Groovy still exists.) Jython was almost the last holdout for targeting the JVM, and it’s also effectively dead. JRuby is... surprisingly alive? But I don’t believe it has tooling worth a damn. I guess what I want to say is, for a very long time—though not for the entirety of its history—it’s been an ecosystem centered on Java and not really on the JVM. Microsoft’s CLR actually made a fair attempt at, let’s say, multilingualism for significantly longer, but after the DLR flopped that was mostly the end of that. And, of course, instead of a Java-centric ecosystem it was from the start a Microsoft-centric ecosystem, and after the stunts they’ve pulled (most recently) with their VSCode extensions and language servers I don’t trust any development tool Microsoft releases to continue to exist in any given form for any given duration. So I don’t think there’s really anything mature that would be VM-centric in the way that Wasm is, that would furthermore not go up in smoke if a single vendor decided to pull out. That’s not to say I think Wasm is the pinnacle of computing–I think it’s pretty wasteful, actually, and annoyingly restrictive in what languages it can support. I just don’t think it really retreads the paths of any of the (two) existing prominent VM-based platforms.

boomskats 1y ago

> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're implying here. > The browser is the main driving force for WASM, as I see it This hasn't been the case for a while. In your first paragraph you yourself say that 'the people furthering WASM are [...] building a whole new VM ecosystem that the browser people aren't interested in' - if that's the case, how can the browser be the main driving force for Wasm? It's true, though, that there's verey little revenue in browser-based Wasm. There is revenue in enterprise compute. > because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container Not exactly true when you consider that docker containers are orders of magnitude bigger, slower to mirror and start up, require architecture specific binaries, are not great at actually 'containing' fallout from insecure code, supply chain vulns, etc.. The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. They just rarely make it to the hn frontpage, because they really are boring. However, the Wasm push in enterprise compute is real, and the value is real. But you're right that the ecosystem and its sponsorship is still struggling - in some part due to lack of support for the component model by the browser people. The component model support introduced in go 1.25 has been huge though, at least for the (imho bigger) enterprise compute use case, and the upcoming update to the component model (wasi p3) should make a ton of this stuff way more usable. So it's a really interesting time for Wasm.

serbuvlad 1y ago
> The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. What are you talking about? Alpine container image is <5MB. Debian container image (if you really need glibc) is 30MB. wasmtime is 50MB. If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too. Also, Docker images get overlayed. So if I have many Go or Rust apps running on Alpine or Debian as simple static binaries, the 5MB/30MB base system only exists once. (Same as a wasmtime binary running multiple programs).
- rkangel 1y ago
  These numbers are true, but you'd be amazed and the number of organisations that have containers that are just based on ubuntu:latest, and don't strip package cache etc.
  - nightpool 1y ago
    Surely moving those containers to alpine would be 1000x easier than rewriting everything in wasm though.
  - serbuvlad 1y ago
    ubuntu:latest is also 30MB, like Debian. Obviously an unoptimized C++/Python stack that depends on a billion .so's (specific versions only) and pip packages is going to waste space. The advantage of containers for these apps is that it can "contain" the problem, without having to rewrite them. The "modern" languages: Go and Rust produce apps that depend either only on glibc (Rust) or on nothing at all (Rust w/ musl and Go). You can plop these binaries on any Linux system and they will "just work" (provided the kernel isn't ancient). Sure, the binaries can be fat, but it's a few dozen megabytes at the worst. This is not an issue as long as you architect around it (prefer busybox-style everything-in-a-binary to coreutils-style many-binaries). Moreover, a VM isn't much necessary, as these programming languages can be easily cross-compiled (especially Go, for which I have the most experience). Compared to C/C++ where cross-compiling is a massive pain which led to Java and it's VM dominating because it made cross-compilation unnecessary, I can run `GOOS=windows GOARCH=arm64 go build` and build a native windows arm64 binary from x86-64 Linux with nothing but the standard Go compiler. The advantage of containers for Rust and Go lies in orchestration and separation of filesystem, user, ipc etc. namespaces. Especially orchestration in a distributed (cluster) environment. These containers need nothing more than the Alpine environment, configs, static data and the binary to run. I fail to see what problem WASM is trying to solve in this space.

pjmlp 1y ago

Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.

mananaysiempre 1y ago
Already-established single-vendor VM ecosystems.
- pjmlp 1y ago
  On the contrary, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.wikipedia.org/wiki/List_of_Java_virtual_machines And looking at other bytecode based systems, enough runtimes with multiple vendors. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode
  - mananaysiempre 1y ago
    I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of guys in a room in 1997 and last had a feature added to it in 2000. So I can’t help observing the non-obsolete JVMs not targeting an embedded usecase (and thus capable of supporting the kind of tools you’re referring to) are all either research projects or OpenJDK-based (or both). Harmony is dead. GCJ is dead. (Does Dalvik count?..) Oracle has already perpetrated half of a rugpull on OpenJDK and mostly murdered the JCP, and that ratchet only ever goes in one direction. And the tooling of the kind you describe is mostly sold by a handful of companies for a handful of notable languages, none of which were born outside the JVM context: Kotlin is the last entrant there, and it is very good, but the tooling is also very distinctly a single-vendor thing to the point that Google didn’t roll their own. (Both Clojure and Scala are lovely, but I don’t think they’re on the same side of notable as Java or Kotlin. Groovy still exists.) Jython was almost the last holdout for targeting the JVM, and it’s also effectively dead. JRuby is... surprisingly alive? But I don’t believe it has tooling worth a damn. I guess what I want to say is, for a very long time—though not for the entirety of its history—it’s been an ecosystem centered on Java and not really on the JVM. Microsoft’s CLR actually made a fair attempt at, let’s say, multilingualism for significantly longer, but after the DLR flopped that was mostly the end of that. And, of course, instead of a Java-centric ecosystem it was from the start a Microsoft-centric ecosystem, and after the stunts they’ve pulled (most recently) with their VSCode extensions and language servers I don’t trust any development tool Microsoft releases to continue to exist in any given form for any given duration. So I don’t think there’s really anything mature that would be VM-centric in the way that Wasm is, that would furthermore not go up in smoke if a single vendor decided to pull out. That’s not to say I think Wasm is the pinnacle of computing–I think it’s pretty wasteful, actually, and annoyingly restrictive in what languages it can support. I just don’t think it really retreads the paths of any of the (two) existing prominent VM-based platforms.