Wasn't this the idea of the JVM?

Java bytecode was originally never intended to be used with anything other than Java - unlike WASM it's very much designed to describe programs using virtual dispatch and automatic memory management. Sun eventually added stuff like invokedynamic to make it easier to implement dynamic languages (at the time, stuff like Ruby and Python), but it was always a bit of round peg in square hole.

By comparison, WASM is really more like traditional assembly, only running inside a sandbox.

	▲	pjmlp 4 months ago \| parent [-]
		Just like CLR bytecode, IBM i TIMI bytecode and many others since 1958. For some reason when people advocate for WASM outside of the browser, they only remember of the JVM.

▲

90s_dev 4 months ago | parent | prev | next [-]

I think so, but that was the 90s where we needed a lot more hindsight to get it right. Plus that was mostly just Sun, right? WASM is backed by all browsers and it looks like MS might be looking at bridging it with its own kernel or something?

▲

bgwalter 4 months ago | parent | next [-]

I don't know. The integration of Java applets was way smoother than WASM.

Security wise, perhaps a different story, though let's wait until WASM is in wide use with filesystem access and bugs start to appear.

	▲	berkes 4 months ago \| parent [-]
		I understand why, but still lament that java applets where dropped like a hot potato, rather than solving the (fundamental) issues. Back then, I learned Java, just to have fancy menus, quirky gimmicks and such. Until flash came along, nothing could do this. Where Java was rather open, free/libre, flash was proprietary and even patented. A big step back. And it took decades before JavaScript reached parity in possibilities to create such interactive, multimedia experiences in a cross-browserish way. I can only imagine how much further along something like videoconferencing, realtime collaboration or gaming on the web would've been if this Java applet tech had been ever improving since inception. (edit: I'm all for semantic, accessible ,clean HTML/CSS/JS in my web apps. But there's lots of use cases for gimmicks, fancy visuals, immersive experiences etc. and no, that's not the hotel-reservation-form or the hackers-forum. But art. Or fun. Or ?)

▲

lloeki 4 months ago | parent | prev [-]

> that was the 90s

In the meantime the CLR happened too.

And - to an extent - LLVM IR.

▲

foldr 4 months ago | parent | prev | next [-]

And of course the ill-fated Parrot VM associated with the Perl 6 project.

▲

rhdjsjebshjffn 4 months ago | parent [-]

I think that was more of a language-oriented effort rather than runtime/abi oriented effort.

▲

foldr 4 months ago | parent [-]

Parrot was intended to be a universal VM. It wasn’t just for Perl.

https://www.slideshare.net/slideshow/the-parrot-vm/2126925

▲

rhdjsjebshjffn 4 months ago | parent [-]

Sure, I just think that's a very odd way to characterize the project. Basically anything can be universal vm if you put enough effort to reimplementing the languages. Much of what sets Parrot aside is its support for frontend tooling.

▲

foldr 4 months ago | parent [-]

“The Parrot VM aims to be a universal virtual machine for dynamic languages…”

That’s how the people working on the project characterized it.

	▲	rhdjsjebshjffn 4 months ago \| parent [-]
		I certainly think the humor in parrot/rakudo (and why they come up today still) is how little of their own self image the proponents could perceive. The absolute irony of thinking that perl's strength was due to familiarity with text-manipulation rather than the cultural mass....

▲

taf2 4 months ago | parent | prev [-]

It’s not a bad idea. Lot of the same people who worked on JVM were around while the asm - wasm ideas emerged