News for hackers. Stuff that matters.
Re:Making WebAssembly better for Rust and for all languages by fulafel on Wednesday March 14, 2018 @01:05PM (#16586285)
This has been tried many times in the history of computing (ANDF/TenDRA, JVM, NaCL, P-code, TIMI, etc). What's different this time?
Re:Making WebAssembly better for Rust and for all languages by lambda on Wednesday March 14, 2018 @01:17PM (#16586425)
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.

Re:Making WebAssembly better for Rust and for all languages by narag on Wednesday March 14, 2018 @01:37PM (#16586629)
...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.

Re:Making WebAssembly better for Rust and for all languages by harpocrates on Wednesday March 14, 2018 @01:07PM (#16586311)
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?

Re:Making WebAssembly better for Rust and for all languages by pjmlp on Wednesday March 14, 2018 @06:26PM (#16588892)
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.

Re:Making WebAssembly better for Rust and for all languages by fulafel on Wednesday March 14, 2018 @01:11PM (#16586353)
As far as I know, all of them match WebAssembly on those points. Though most are far back in history and not current rivals.
Re:Making WebAssembly better for Rust and for all languages by protomyth on Wednesday March 14, 2018 @01:28PM (#16586538)
UCSD p-machine?
Re:Making WebAssembly better for Rust and for all languages by e12e on Wednesday March 14, 2018 @06:07PM (#16588761)
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)?
Re:Making WebAssembly better for Rust and for all languages by imtringued on Thursday March 15, 2018 @08:13AM (#16592120)
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.
Re:Making WebAssembly better for Rust and for all languages by AgentME on Wednesday March 14, 2018 @02:03PM (#16586876)
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.
Re:Making WebAssembly better for Rust and for all languages by seanmcdirmid on Wednesday March 14, 2018 @05:01PM (#16588254)
> 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.

Re:Making WebAssembly better for Rust and for all languages by pjmlp on Wednesday March 14, 2018 @06:29PM (#16588917)
There are still quite a few JVM implementations still, they just tend to be specialized in embedded, military or factory automation systems.
Re:Making WebAssembly better for Rust and for all languages by monocasa on Wednesday March 14, 2018 @09:04PM (#16589735)
* 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.

Re:Making WebAssembly better for Rust and for all languages by skybrian on Wednesday March 14, 2018 @01:23PM (#16586484)
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.

Re:Making WebAssembly better for Rust and for all languages by jcelerier on Wednesday March 14, 2018 @06:10PM (#16588784)
> None of them run in a browser

some used to, until browsers banned them

Re:Making WebAssembly better for Rust and for all languages by monocasa on Thursday March 15, 2018 @10:37AM (#16593201)
Because they couldn't get their shit together from a sandboxing perspective.
Re:Making WebAssembly better for Rust and for all languages by zem on Wednesday March 14, 2018 @01:16PM (#16586416)
languages are actually eager to target it
Re:Making WebAssembly better for Rust and for all languages by oblio on Wednesday March 14, 2018 @01:31PM (#16586564)
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.
Re:Making WebAssembly better for Rust and for all languages by zem on Wednesday March 14, 2018 @05:56PM (#16588674)
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.