4 ms·

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.

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.

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.