Hacker News new | ask | show | jobs
by fulafel 3022 days ago
This has been tried many times in the history of computing (ANDF/TenDRA, JVM, NaCL, P-code, TIMI, etc). What's different this time?
6 comments

It's a true open standard developed collaboratively by multiple competing top-tier companies, has multiple interoperable implementations, has been designed from the ground up for running untrusted code in a sandboxed environment, has been designed to be a general-purpose compilation target rather than with tight coupling to a specific source language, it has enough killer apps that is will likely continue to be developed and supported by these multiple companies, and it was developed with the hindsight of many of these previous failed or only partially successful efforts.

Some of these previous efforts might have one or two of these features, but none of them meet all of these criteria.

...and it was developed with the hindsight of many of these previous failed or only partially successful efforts.

You seem to imply this approach wasn't successful before. IMHO it's been successful, more than once actually, just not awesome.

What other low-level format supports my points (a), (b), and (c)? And has an actual spec?

EDIT: you've since added some examples. Here are my (very subjective) opinions:

- The JVM isn't really all that low-level - it eeks out a lot of performance at runtime. Plus, you need to have GC, which tends to increase memory requirements and complicate real-time constraints.

- NaCL was interesting but its spec wasn't as good. IIRC Google didn't do too much in the way of asking for public input. I think some folks had some security concerns too. I really like WebAssembly's spec - I don't see any typing judgements or small-step rules for NaCL.

- Wasn't ANDF unix-bound?

Mesa in Xerox Star, TIMI in IBM i, Language Environment on IBM z, MCP in Unisys ClearPath, UCSD Machines are some of the most well known examples.

Using bytecode as portable executable format has been a tradition in mainframes since the early 60's.

As far as I know, all of them match WebAssembly on those points. Though most are far back in history and not current rivals.
UCSD p-machine?
I'm not very familiar with the various jvm profiles - but isn't javacard pretty light? (the stuff that runs on similar cards and such)?
Yes but you're still bound to java semantics. Java is very high level. Almost everything except the blessed primtives long/int/short/byte is an object. This is not a suitable target for lower level languages like C.
While some of those were open standards, most/all of those only ever had a single implementation each. JVM's startup time is painful, and its sandboxing abilities have been frequently broken. Wasn't Microsoft p-code interpreted, or are you referring to something else? NaCL was still architecture-specific until PNaCL. PNaCL is pretty comparable to WebAssembly besides that PNaCL was driven by Google alone, and WebAssembly was worked on by many players after it evolved from asm.js.
> most/all of those only ever had a single implementation each.

At its peak, there were many different vendors delivering JVM implementations. How we forget Kaffe, even.

There are still quite a few JVM implementations still, they just tend to be specialized in embedded, military or factory automation systems.
* ANDF/TenDRA - Never really used except for research purposes, ie. no critical mass.

* JVM - Most heavily used implementation borked the sandboxing. It also forces a GC down your throat, which is great for 95% of use cases, but the other 5% are really important too.

* NaCl - Really cool, but ultimately reliant on weird CPU features for protection. PNaCl was trying to fit a square peg into a round hole with the whole trying to make LLVM IR platform independent thing. WebAsm took a lot of ideas from these projects (and asm.js).

* P-Code - Really cool, but ultimately probably a victim of it's time. A little simplistic for modern architectures as it has no real concept of a memory model or atomic primitives.

* TIMI - Unbelievably proprietary. Even if you were to document it well enough to build an implementation, IBM would almost certainly sue you into oblivion.

None of them run in a browser (though some tried). And now that WebAssembly is the standard, they probably won't get another chance.

And the reason running in a browser matters is that it guarantees a lot of teams will put effort into improving it.

> None of them run in a browser

some used to, until browsers banned them

Because they couldn't get their shit together from a sandboxing perspective.
languages are actually eager to target it
Yeah, the social factor is way more important. We might actually get WORA that can't be blocked by a walled garden, cause it would be a suicidal move for whichever company does it.
it's not just the social factor, it's that there's an immediate benefit to using it - your code can be run in a web browser. that solves the bootstrapping problem with your shiny new WORA bytecode spec being unattractive until there are already a bunch of implementations, but there won't be a bunch of implementations until people are actively using it.