They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible.
What we _really_ need is a sandboxed VM for running C code securely and efficiently.
The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code.
We're hoping WASM starts over from scratch and does things right this time around.
UNIX is thoroughly obsolete. Its continued use is from inetia; people rarely need anything but a tiny subset of its capabilities, for which there are more simpler alternatives every day.
are you kidding? do you know how many subsystems that people take for granted are using UNIX? furthermore, how do you get simpler than UNIX? it's not complex..
A decade and change has passed, so we get to do it against a new set of I/O concepts and performance concerns. Those are always the factors motivating new software standards.
I did evaluate WASM as a native runtime environment recently, pre-WASI. If what you're doing can coexist with memory mapped I/O, you don't have to have an explicit interface of this type, you can just say "lower region of linear memory is where the I/O goes" and hardcode all APIs against that. It's more "honest" in certain ways than a syscall interface since it doesn't lead to any parsing of intent or variable expectations around resource usage.
Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/Rust being 1st class citizens is also very useful.
Standard libraries are what make languages useable. In my experience there's a solid case to be made for a 10-ton standard library (for targets with an operating system) or basically none whatsoever (for embedded). A thin standard library is always going to be too small to do useful things easily at the high level and too big to be deployed on an embedded system. Rust is good because it can play in both sandboxes.
For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?
Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?
Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.
Rapid prototyping, replacement for a scripting facility, diagnostics filtering & output, a platform for "apps" for a small IoT type devices and just the ability to run the same plugin anywhere you please.
It can be an enabler for new innovations. Even if it runs 2-10x slower than native code.
And what if the answer was just: just because I can? That's how a lot in our industry got started.
.NET's '10 tonne' standard library is a decent part of what makes it so usable. And it's not exactly massive either - I can publish a standalone .NET Core app that's only around 30MB in size. For the usability and GC, I'll take that over C any day.
That will probably come done quiet a bit when illink gets out of alpha. It is basically a tree-shaker to eliminate dead/unused stuff from the resulting standalone binary.
A tree shaking linker will definitely help a lot, but there's still some runtime baggage that probably can't be removed. For instance, dynamic loading and all of the related type and assembly metadata structures. I look forward to seeing what they can do!
Does it matter? I don't really see the issue with competing standards if the standards are open: The "best" (for some definition of best) should win out eventually.
We could re-implement C as well, but is it sensible if we already have C?
If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here.
As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely in native environments. I'm a younger developer and only partly remember the days of Java on the web, but is there a reason for why JVM is not suitable in web environments? I.e. why WebAssembly -> Native, not JVM -> Web?
I've now found a blog post[0], which seems to outline two main reasons for WASM over JVM on the web:
1. WASM is an open standard
2. WASM spec is smaller, so it's easier to integrate into the Javascript VM, which itself brings many benefits
Since WASM wins on the web, I guess it makes sense for developers to want to develop one version of their code for both the web as well as native environments. Thus, WASM -> Native seems to totally make sense.
So is the web, but that didn't stop anyone from extending it in incompatible ways and all implementations being subtly different enough that you still have care about which one you're running on and, oh yeah, it's also becoming dominated by a single player who steers the whole thing pretty much wherever they want it.
Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them
The JVM and CLR seem like they're language platforms first and VMs second
"The JVM and CLR seem like they're language platforms first and VMs second"
Ding ding ding ding ding.
There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the semantics of the actually-targeted language; you'd have a hard time taking a pure C codebase and compiling/running it on the JVM or CLR or BEAM.
WebAssembly is not that much different, technically; its actually-targeted languages are C, C++, and Rust, and you can reasonably think of it as a VM for those languages. However, it seems to be making an effort to not get caught up in the semantics of any specific language, much like how machine code tends to not really care about whether the instructions it's executing were compiled from C or Rust or Java or Ruby or COBOL or Brainfuck.
Parrot was intended as a more universal VM, and was started before the Perl6 design solidified. So in the end it didn't actually fit that well with Perl6.
NQP is a small subset of Perl6 that is used for bootstrapping Perl6, and provides an isolation layer from the vagaries of the various VMs it targets. It used to target Parrot, and now targets MoarVM, the JVM, and JavaScript. (NQP is an acronym for Not Quite Perl6.)
MoarVM (Metamodel On A Runtime) was built specifically for Perl6, but its design is minimal. Most of the Perl6 specific features are built using Perl6 and NQP.
For example, MoarVM only provides only enough of an object/type system to bootstrap the full object system. That is MoarVM gets taught how Perl6 objects work every time it loads the Perl6 runtime.
MoarVM also has a pluggable optimizer where you write the plugins in a higher level language. It could be any language that compiles down to MoarVM bytecode. The Perl6 ones are written in NQP.
I think this dynamism makes MoarVM an interesting target for other languages.
Makes me wonder: is there any language implemented on the JVM that works around the JVM GC the way asm.js works around the js GC? Would it even be possible, could it be performant?
Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. They moved to mono, so that isn't true now.
> If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot.
I'll take a stab at it. While both WASM and the JVM aim to be portable virtual machines, WASM prioritizes sandboxing / security and a smaller runtime. A host should be able to easily set up WASM with restricted access and expect that the WASM program is secure. As far as I know, the JVM doesn't have an equivalent feature, or if it does, it's a lot more complicated.
On the other hand, I seem to remember that the security model was (somewhat) adapted to the threat at hand when it was designed (~25 years ago). I haven't kept tabs on it, so I don't know how well it has aged, but there's a chance it doesn't work anymore.
If something, be it a language or a VM is not up to scratch, it would seem to be a good idea to reimplement it. Would you propose just sticking with the mediocre present instead?
Yes. C is an absolutely terrible programming language that we use because it got their first. I sincerely hope that C (and bad C++, so probably C++ as well) is phased out over the coming years purely because it's too dangerous to use it in critical software (One life lost to memory corruption is too many). This probably won't happen, but I hope it does.
JVM is pretty complicated and not open source(? I'm not entirely sure who owns the standard, if there is one). WebAssembly has the advantage of hindsight and being able to be designed to completion rather than evolved
I'm personally bearish on the whole idea from a community / technical standpoint (in that I'd like us to return to more native stuff than follow JS into the browser), but I can't argue that WASM and co won't enable some really cool uses.
I can't shake the niggling idea that this, just like node before it, is more or less a way for JS web devs to not have to leave the ecosystem they're comfortable with and learn a new language. We already have hundreds of ways to write native UI applications, but web devs can't bother to use them.
When you put WASM into something that isn't a browser then it still won't be a browser afterwards. WASM is not DOM+CSS.
On top of that, JS devs would be the ones who get the short end of the stick, because js is the one language that does not compile to WASM because where WASM comes from, you already have a JS environment, no need to build a second one inside WASM.
Couldn't a native developer also take advantage of wasm/wasi to build their native application to a single build target/binary, which could then be run on Any machine?
But are any of those ways both at the assembly level (speed) and decoupled from the runtime (space)?
My takeaway from WASI is that it would allow for a single universal runtime with near-native execution. The near-native aspect being what other universal runtimes like the JVM and CLR lack due to their bundling of a GC and other non-essential features.
They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible.
What we _really_ need is a sandboxed VM for running C code securely and efficiently.
The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code.
We're hoping WASM starts over from scratch and does things right this time around.