5 ms·

Every thread about WASM is "this is just JVM". No it's not. If you want to know how it's meaningfully different - go look look high level overview of JVM and W

Every thread about WASM is "this is just JVM". No it's not. If you want to know how it's meaningfully different - go look look high level overview of JVM and WASM - and if you still don't get it - then you're probably not the target audience for either and you should just be using whatever the tool stack it's targeting them. A bus and a cargo truck are not the same just because they have similar wheel base/size and abstractly do the same thing.

jeroenhd 3y ago
To me WASM just seems like the JVM without special OOP instructions. It never started out that way, but it certainly is ending up that way. Everything that made WASM stand out from the traditional bytecode VM is being patched back in through extensions like WASI and now WASIX. I was originally excited for WASM because it started out as a fully sandboxed system. No I/O other than flat memory buffers, so no chance whatsoever of escaping its sandbox. Now WASIX introduces networking, file system I/O, mutltithreading, forking, even TTY support. It's not as powerful as the JVM yet, but give it a few years and I'm sure you can use them interchangeably in a few years.
- ShroudedNight 3y ago
  This reminds me of the old adage that the most secure computer is one that has never been, and can never connect to anything. It's also rather limited in its usefulness.
  - jeroenhd 3y ago
    The limitations are what made WASM attractive to me. If I want a fast component to re-encode images, or to render a 3D scene, or to analyze and transform data, I don't want to have to set up a network namespace, alternate file system roots, and all the other annoying stuff that comes with sandboxing. WASM not being able to do or access anything you don't manually provide allows for quickly and easily hooking in executable code without the normal risks. Add enough extensions to the runtime everyone uses and you end up with another JVM. The JVM is very good and so is the .NET runtime and any other bytecode runtime you can think of, but the distinctions start to fade as more features get tacked onto WASM.
- moonchrome 3y ago
  You can use cargo trucks to transport people and buses to transport cargo - so they are interchangeable ? "Special OOP instructions" - you mean like object model and garbage collection ? WASI is aiming to run in the browser sandbox which means it's API interface has to be more sandboxable than POSIX. Implementing POSIX compatibility layers on top of it is going to be leaky.
  - deleted 3y ago
    [deleted]
  - jeroenhd 3y ago
    If you cut out the seats, attach a trailer hook up, put up a sheet behind the driver, and lower the engine, then you've created a truck out of a bus. There was no reason to turn a bus into a cargo truck and the result isn't better than any existing cargo truck, but your transformation altered what the original vehicle is likely to be used for. Removing the limitations that make WASM such a safe system to implement and replacing it with POSIX system calls is like ripping out the seats and replacing them with a trailer hook up. There's nothing wrong with being able to attach large trailers to your vehicle, but the type of vehicle you're converting may be better off without your alterations. The JVM contains instructions such as instanceof and various ways to invoke a method that mirror the OOP approach of Java. Garbage collection instructions are also extensively used, of course, but they're not as OOP specific. Unlike WASI, WASIX adds open()/read()/write()/close() to WASI. It also adds fork(), exec(), and wait(). With modern web APIs (such as the filesystem API) many of these can be added without any virtual implementations, but WASI and WASIX are also targetting other use cases. One use case being pushed by a lot of WASM companies is for WASM to replace Docker containers in a Kubernetes cluster, for example.
- kelp 3y ago
  WASM won't be able to get any real level of adoption if you have to specifically write all your code to target it, which I think is what would happen if the sandbox is too restrictive. If you can trivially move existing code to run in a WASM VM you get the benefits of isolation and a convenient artifact to move around for deployment and scheduling. I think the history of successful platforms are ones that still supported the old way of doing things, while enabling a new and better way. Of course that comes with lots of tradeoffs that are often hard to stomach.
  - jeroenhd 3y ago
    I agree that "WASM as a generic target platform" is the best way for WASM to gain popularity and actually get used. However, that would make it end up as "Java but different". That's not a bad thing, there's absolutely nothing wrong with Java as a technological concept!
zdragnar 3y ago
> A bus and a cargo truck are not the same The redneck engineer in me disagrees.
tyingq 3y ago
I see your point for how things are now, but the WASM roadmap and proposals do have several things on it that take it into territory that's closer to the JVM.
pjmlp 3y ago
Here is the thing, there isn't only the JVM, plenty of examples since late 1950's. Arguing that WASM isn't JVM as defence, while forgetting computing history isn't great either.
- vinkelhake 3y ago
  What's forgotten? Do you have any favorite bytecodes from the 50's that you want resurrected?
  - pjmlp 3y ago
    Interlisp-D for one would be nice, I guess. And it isn't from the 1950's, it is since then.

jeroenhd 3y ago

To me WASM just seems like the JVM without special OOP instructions. It never started out that way, but it certainly is ending up that way. Everything that made WASM stand out from the traditional bytecode VM is being patched back in through extensions like WASI and now WASIX. I was originally excited for WASM because it started out as a fully sandboxed system. No I/O other than flat memory buffers, so no chance whatsoever of escaping its sandbox. Now WASIX introduces networking, file system I/O, mutltithreading, forking, even TTY support. It's not as powerful as the JVM yet, but give it a few years and I'm sure you can use them interchangeably in a few years.

ShroudedNight 3y ago
This reminds me of the old adage that the most secure computer is one that has never been, and can never connect to anything. It's also rather limited in its usefulness.
- jeroenhd 3y ago
  The limitations are what made WASM attractive to me. If I want a fast component to re-encode images, or to render a 3D scene, or to analyze and transform data, I don't want to have to set up a network namespace, alternate file system roots, and all the other annoying stuff that comes with sandboxing. WASM not being able to do or access anything you don't manually provide allows for quickly and easily hooking in executable code without the normal risks. Add enough extensions to the runtime everyone uses and you end up with another JVM. The JVM is very good and so is the .NET runtime and any other bytecode runtime you can think of, but the distinctions start to fade as more features get tacked onto WASM.
moonchrome 3y ago
You can use cargo trucks to transport people and buses to transport cargo - so they are interchangeable ? "Special OOP instructions" - you mean like object model and garbage collection ? WASI is aiming to run in the browser sandbox which means it's API interface has to be more sandboxable than POSIX. Implementing POSIX compatibility layers on top of it is going to be leaky.
- deleted 3y ago
  [deleted]
- jeroenhd 3y ago
  If you cut out the seats, attach a trailer hook up, put up a sheet behind the driver, and lower the engine, then you've created a truck out of a bus. There was no reason to turn a bus into a cargo truck and the result isn't better than any existing cargo truck, but your transformation altered what the original vehicle is likely to be used for. Removing the limitations that make WASM such a safe system to implement and replacing it with POSIX system calls is like ripping out the seats and replacing them with a trailer hook up. There's nothing wrong with being able to attach large trailers to your vehicle, but the type of vehicle you're converting may be better off without your alterations. The JVM contains instructions such as instanceof and various ways to invoke a method that mirror the OOP approach of Java. Garbage collection instructions are also extensively used, of course, but they're not as OOP specific. Unlike WASI, WASIX adds open()/read()/write()/close() to WASI. It also adds fork(), exec(), and wait(). With modern web APIs (such as the filesystem API) many of these can be added without any virtual implementations, but WASI and WASIX are also targetting other use cases. One use case being pushed by a lot of WASM companies is for WASM to replace Docker containers in a Kubernetes cluster, for example.
kelp 3y ago
WASM won't be able to get any real level of adoption if you have to specifically write all your code to target it, which I think is what would happen if the sandbox is too restrictive. If you can trivially move existing code to run in a WASM VM you get the benefits of isolation and a convenient artifact to move around for deployment and scheduling. I think the history of successful platforms are ones that still supported the old way of doing things, while enabling a new and better way. Of course that comes with lots of tradeoffs that are often hard to stomach.
- jeroenhd 3y ago
  I agree that "WASM as a generic target platform" is the best way for WASM to gain popularity and actually get used. However, that would make it end up as "Java but different". That's not a bad thing, there's absolutely nothing wrong with Java as a technological concept!

zdragnar 3y ago

> A bus and a cargo truck are not the same The redneck engineer in me disagrees.

tyingq 3y ago

I see your point for how things are now, but the WASM roadmap and proposals do have several things on it that take it into territory that's closer to the JVM.

pjmlp 3y ago

Here is the thing, there isn't only the JVM, plenty of examples since late 1950's. Arguing that WASM isn't JVM as defence, while forgetting computing history isn't great either.

vinkelhake 3y ago
What's forgotten? Do you have any favorite bytecodes from the 50's that you want resurrected?
- pjmlp 3y ago
  Interlisp-D for one would be nice, I guess. And it isn't from the 1950's, it is since then.