7 ms·

At some point we need to stop inventing VMs. VMs like Java, .Net, etc, are already good enough. What is the point of yet another VM? The same people who designe

At some point we need to stop inventing VMs. VMs like Java, .Net, etc, are already good enough. What is the point of yet another VM? The same people who designed web assembly could have taken java bytecode and added new APIs on top. Instead, they invented yet another machine encoding that has to be targeted, except this time we get to re-invent all the tooling. Look... I hate the Java language with a burning passion, but the Java VM core technology is perfectly acceptable. So is .Net. There is no reason for webassembly, other than that mozilla wanted to invent something.

infogulch 5y ago
We're biased towards additive solutions [0], but sometimes subtraction is the right answer to a design problem. The problems that WA aims to solve from existing VMs like JVM/.NET are caused by the old APIs themselves, adding more API surface would not help. [0]: Adding is favoured over subtracting in problem solving https://news.ycombinator.com/item?id=26727878 https://news.ycombinator.com/item?id=26727878
- brundolf 5y ago
  Sometimes adding the right thing can give you the opportunity to subtract. Code running in WASM may not have to run inside a Docker container running inside a Linux VM.
  - iammisc 5y ago
    Nothing needs to run Ina container Containers are just software engineerings latest name for a unix process. Both were designed to achieve similar levels of isolation. In reality,there's no such thing as a container. As far as Linux is concerned, containers are just processes with attributes, because that's what they are, we just decided to complicate it a lot
- iammisc 5y ago
  Okay then define a subset of java opcodes supported and then modify the open source hotspot. Look I'm trying to implement a wasm backend into an existing language right now and it could be a lot easier by either making wasm into a real architecture (with registers) or using an existing stack based vm isa.
  - UncleEntity 5y ago
    Couldn’t wasm be compiled down to either a stack or register based VM equally well? The text version is basically an ast (with the binary form being a desugared version of that) so you could do whatever you want to transform into something executable.
    - iammisc 5y ago
      No. WASM is fundamentally a stack machine. That's how its semantics are defined.
      - sitkack 5y ago
        It is a mechanical transformation from stack to registers. In other parts of the thread you mentioned TCO, one can also convert recursion into iteration, tail calls can be handled by the compiler or with a trampoline. The universe is much more flexible than you give it credit for.
        iammisc 5y ago
        Recursion can be converted to iteration very easily but then you lose all benefits of web assembly (dynamic linking, for example(. The conversion from recursion to iteration mandates that all recursive entry points be known ahead of time so you can build a loop/conditional tree. If you want to dynamically load code, this creates two tiers of languages on the runtime. You really think I haven't thought of this?
  - infogulch 5y ago
    WA can be transformed into native machine code in linear time, directly executed at (near) native speed, while retaining the VM memory protection barrier. No other VM can come close in these three properties at once. If you're trying to integrate WA into a host language the easiest, fastest, and safest way would be to pick up one of the established well-polished compilers or interpreters and calling into it with a standard FFI interface.
- pjmlp 5y ago
  Just wait until WebAssembly actually moves beyond the MVP, which is stuck at.
unrealhoang 5y ago
I know right, everyone wants to make their own VM become "the one" for computing to collect the sweet sweet tax. If only the major companies sit together and agree upon a standard and let multiple VM implementations compete in an open-source manner ... oh wait, that's wasm.
- iammisc 5y ago
  .net is an open ieee standard with several implementations. Java is too at this point Both are more advanced
tiew9Vii 5y ago
The JVM does way more than Webassembly, completely different runtime characteristics. Webassembly is not attempting to be or do anything near what the JVM does. Webassembly was designed for sandboxing untrusted code in a webbrowser, giving native like performance and limited functionality. It just so happened the same characteristics for running untrusted code in the browser work really well for usecases people use AWS Lambda for etc. You have small lightweight applications that have limited system access you need to binpack and have fast startup / low overhead. Webassembly/WASI isn't replacing the JVM/.NET, it's providing an alternative for specific use cases, running untrusted code in isolated environments that is fast and light weight.
- pjmlp 5y ago
  It is only going to be fast and light weight if we get stuck with MVP 1.0, supporting only C, C++ and Rust, with hacks for the remaining languages. 20 years ago I was running untrusted code in isolated environments via application containers like HP-UX Vault and later Java Application Servers.
  - iammisc 5y ago
    Exactly. Web assembly doesn't support basic features like tail calls (neither does java), which are vital for whole classes of languages. This is where silicon excels... at letting you actually implement languages in the best way, instead of forcing you to think in particular paradigms. I believe .NET/CLR supports tail call optimization (I think it must for F#).
    - pjmlp 5y ago
      F# came later into the game, CLR was designed as COM evolution and was supposed to be for VB, C#, J# (evolution from J++ and migration path to .NET), and C++ (initially Managed C++, the C++/CLI with .NET 2.0). On top of that, Microsoft enganged with the language community so that there were about 20 other languages available for .NET 1.0 on release date. Here, diggging through the archives, https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/... > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. Naturally MSIL had to support all of them. The dynamic runtime came later as side effect from IronPython and IronRuby efforts. Naturally WebAssembly folks are going to tell you they are the very first of this kind of efforts.
mftb 5y ago
This, "...other than that mozilla wanted to invent something." Is not what happened. The browser vendors; Apple, MS, Google and Mozilla, whatever their reasons, decided they were going to kill Java and Flash in the browser. They then flailed about with NACL and other things, before Mozilla put forward WASM and they again, for whatever their reasons, accepted it. Complaining about it now, at least a decade late, is just weird to me. WASM isn't of interest because it's another VM, it's because it's the only VM that runs in the browsers (and soon lots of other places).
- iammisc 5y ago
  I understand that. I'm not saying WASM isn't of interest. On the contrary, since I'm currently implementing language support for WASM, I'd say it's very important. What I am saying is that it is Java VM 2.0. The java ISA was perfectly fine. People knew how it worked, there was lots of tooling, etc. Instead of building off that, they made something new... just because. WASM is technically inferior to java, and is based upon the same basic principles. It's just like java bytecode in the 90s. It's not even done yet. This is a terrible mess.

infogulch 5y ago

We're biased towards additive solutions [0], but sometimes subtraction is the right answer to a design problem. The problems that WA aims to solve from existing VMs like JVM/.NET are caused by the old APIs themselves, adding more API surface would not help. [0]: Adding is favoured over subtracting in problem solving https://news.ycombinator.com/item?id=26727878 https://news.ycombinator.com/item?id=26727878

brundolf 5y ago
Sometimes adding the right thing can give you the opportunity to subtract. Code running in WASM may not have to run inside a Docker container running inside a Linux VM.
- iammisc 5y ago
  Nothing needs to run Ina container Containers are just software engineerings latest name for a unix process. Both were designed to achieve similar levels of isolation. In reality,there's no such thing as a container. As far as Linux is concerned, containers are just processes with attributes, because that's what they are, we just decided to complicate it a lot
iammisc 5y ago
Okay then define a subset of java opcodes supported and then modify the open source hotspot. Look I'm trying to implement a wasm backend into an existing language right now and it could be a lot easier by either making wasm into a real architecture (with registers) or using an existing stack based vm isa.
- UncleEntity 5y ago
  Couldn’t wasm be compiled down to either a stack or register based VM equally well? The text version is basically an ast (with the binary form being a desugared version of that) so you could do whatever you want to transform into something executable.
  - iammisc 5y ago
    No. WASM is fundamentally a stack machine. That's how its semantics are defined.
    - sitkack 5y ago
      It is a mechanical transformation from stack to registers. In other parts of the thread you mentioned TCO, one can also convert recursion into iteration, tail calls can be handled by the compiler or with a trampoline. The universe is much more flexible than you give it credit for.
      - iammisc 5y ago
        Recursion can be converted to iteration very easily but then you lose all benefits of web assembly (dynamic linking, for example(. The conversion from recursion to iteration mandates that all recursive entry points be known ahead of time so you can build a loop/conditional tree. If you want to dynamically load code, this creates two tiers of languages on the runtime. You really think I haven't thought of this?
- infogulch 5y ago
  WA can be transformed into native machine code in linear time, directly executed at (near) native speed, while retaining the VM memory protection barrier. No other VM can come close in these three properties at once. If you're trying to integrate WA into a host language the easiest, fastest, and safest way would be to pick up one of the established well-polished compilers or interpreters and calling into it with a standard FFI interface.
pjmlp 5y ago
Just wait until WebAssembly actually moves beyond the MVP, which is stuck at.

unrealhoang 5y ago

I know right, everyone wants to make their own VM become "the one" for computing to collect the sweet sweet tax. If only the major companies sit together and agree upon a standard and let multiple VM implementations compete in an open-source manner ... oh wait, that's wasm.

iammisc 5y ago
.net is an open ieee standard with several implementations. Java is too at this point Both are more advanced

tiew9Vii 5y ago

The JVM does way more than Webassembly, completely different runtime characteristics. Webassembly is not attempting to be or do anything near what the JVM does. Webassembly was designed for sandboxing untrusted code in a webbrowser, giving native like performance and limited functionality. It just so happened the same characteristics for running untrusted code in the browser work really well for usecases people use AWS Lambda for etc. You have small lightweight applications that have limited system access you need to binpack and have fast startup / low overhead. Webassembly/WASI isn't replacing the JVM/.NET, it's providing an alternative for specific use cases, running untrusted code in isolated environments that is fast and light weight.

pjmlp 5y ago
It is only going to be fast and light weight if we get stuck with MVP 1.0, supporting only C, C++ and Rust, with hacks for the remaining languages. 20 years ago I was running untrusted code in isolated environments via application containers like HP-UX Vault and later Java Application Servers.
- iammisc 5y ago
  Exactly. Web assembly doesn't support basic features like tail calls (neither does java), which are vital for whole classes of languages. This is where silicon excels... at letting you actually implement languages in the best way, instead of forcing you to think in particular paradigms. I believe .NET/CLR supports tail call optimization (I think it must for F#).
  - pjmlp 5y ago
    F# came later into the game, CLR was designed as COM evolution and was supposed to be for VB, C#, J# (evolution from J++ and migration path to .NET), and C++ (initially Managed C++, the C++/CLI with .NET 2.0). On top of that, Microsoft enganged with the language community so that there were about 20 other languages available for .NET 1.0 on release date. Here, diggging through the archives, https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/... > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. Naturally MSIL had to support all of them. The dynamic runtime came later as side effect from IronPython and IronRuby efforts. Naturally WebAssembly folks are going to tell you they are the very first of this kind of efforts.

mftb 5y ago

This, "...other than that mozilla wanted to invent something." Is not what happened. The browser vendors; Apple, MS, Google and Mozilla, whatever their reasons, decided they were going to kill Java and Flash in the browser. They then flailed about with NACL and other things, before Mozilla put forward WASM and they again, for whatever their reasons, accepted it. Complaining about it now, at least a decade late, is just weird to me. WASM isn't of interest because it's another VM, it's because it's the only VM that runs in the browsers (and soon lots of other places).

iammisc 5y ago
I understand that. I'm not saying WASM isn't of interest. On the contrary, since I'm currently implementing language support for WASM, I'd say it's very important. What I am saying is that it is Java VM 2.0. The java ISA was perfectly fine. People knew how it worked, there was lots of tooling, etc. Instead of building off that, they made something new... just because. WASM is technically inferior to java, and is based upon the same basic principles. It's just like java bytecode in the 90s. It's not even done yet. This is a terrible mess.