[harpocrates]

One thing that continues to amaze me is that WebAssembly isn't being discussed more outside of the context of the web. Think about it just as a format that (a) is low-level enough to support performance tricks, (b) is fast to turn into native code, and (c) easy to check.

Compilers could stop worrying about obscure/old architectures. Deploying an application onto multiple platforms is no longer a problem. Sandboxing is much simpler. Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text).

I'm so excited about WebAssembly, but really not because of the web.

[kllrnohj]

> Compilers could stop worrying about obscure/old architectures.

No they wouldn't. They still need to turn WebAsm/IR into assembly, which is the thing they already do today anyway. Nothing changes for compilers, other than the potential for optimizations gets much, much worse as the IR is comparatively crippled and restricted to the IR they already have.

> Deploying an application onto multiple platforms is no longer a problem.

This has never been the result of CPU instructions. That's a library problem, not an IR problem. WebAsm does nothing to help with this, particularly as it intentionally has no real standard library to speak of.

Or put another way every compiled program is already on a perfectly portable IR called x86_64. Runs on just about every desktop, laptop, and nearly every server in the world. Yet good luck writing a portable "hello world" in it.

It marginally reduces your release artifacts as you only produce a single webasm set instead of x86, x86_64, arm7, and armv8, but using webasm instead comes at non-trivial costs, too. Instead of compiling once on a known toolchain you're now compiling millions of times on uncontrolled, unknown toolchains. That's not a great trade-off in many, if not most, circumstances.

> Sandboxing is much simpler.

Sandboxing is already a solved problem using process isolation, which has the nice property of not caring how your process runs at all. What benefit does WebAsm add to this?

> Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text).

WebAsm is an intermediate, not a source. Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all. That doesn't help you verify anything about your code, which was a compiler, optimizer, and god knows what else away from the webasm that was generated.

It's good that the spec is actually a spec, but this isn't a unique trait to webasm and it won't help your code any since your code isn't in webasm. It's still in C/C++, Rust, or whatever else and they all remain just as verifiable (or not) as they always were.

[pcwalton]

> Or put another way every compiled program is already on a perfectly portable IR called x86_64. Runs on just about every desktop, laptop, and nearly every server in the world.

But not mobile.

(Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.)

> Sandboxing is already a solved problem using process isolation

If only it were. Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process.

> Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all.

You can verify memory safety of the compiled code, which is a useful and important property.

(I think nobody seriously doubts that Web Assembly is memory safe assuming a bounds checked heap, though, so it's not that practically interesting of a result. Maybe it'll be more so when GC support lands.)

[kllrnohj]

> (Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.)

Well, x86_64 is actually AMD's creation not Intel's. But replace x86_64 with ARM on mobile and it's the same thing - a portable IR/instruction set does not result in a portable application.

> Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process.

Neither does webasm, other than by just not having any features currently. But that's obviously not a viable long-term strategy, certainly not for anything standalone-ish.

> You can verify memory safety of the compiled code, which is a useful and important property.

My native code is perfectly memory safe as well, enforced in hardware even. Has been that way for decades.

Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. A memory safe IR is meaningless outside of the context of being embedded in another process. Aka, when used in a web browser. Or I guess as a massively overcomplicated replacement for Lua.

But the point is verifying the resulting webasm doesn't mean your code was correct, it means your code plus current toolchain selection happened to result in verified code. Whether or not that was the result of a fluke or well defined behavior is not something webasm has any impact on.

[pcwalton]

> Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway.

That's not true. Web Assembly semantics don't allow interpreting data as code or explicitly messing with the machine stack. This guarantees control flow integrity, preventing problems like ROP or traditional buffer overflows.

[andromeduck]

While webasm isn't vulnurable to traditional ROP attacks, it will also lose at least as much performance penalty as IR + g-free/indirect return.

Memory protection in terms of r/w/x been solved for at least about 3 decades now. It would be absolutely trivial to enforce via binary/IR distribution.

At the end of the day webasm is just a shitty IR that only exists because it's the path of least resistance on the web. There's really no point in going from lang-> llvm -> webasm -> llvm -> exec when you can just go from lang -> llvm -> asm.

[pcwalton]

RWX doesn't prevent ROP!

[comex]

However, it only partially addresses JOP (jump-oriented programming, i.e. hijacking calls to function pointers and virtual methods). And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack. In fact, I expect Clang CFI to be more widely adopted in the future… However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead.

edit: not to mention that WebAssembly is currently missing security mitigations that long have been standard in native code, such as ASLR, and… maybe stack overflow protection? (It looks like emscripten handles the latter manually by checking STACKTOP against STACK_MAX, but I'm not sure LLVM's native WebAssembly target does.) Maybe these will be addressed in the future, but for now there are some interesting exploitation opportunities.

[pcwalton]

> However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead.

But you get a lot more than security for your trouble using Web Assembly. So the performance-vs.-security tradeoff isn't the only part of the calculus here.

> And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack.

Clang CFI only protects indirect calls. And SafeStack looks like it has issues, according to the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=505015

"No. We are currently looking at other alternatives (all look grim, though). Before trying to proceed with SafeStack please get the agreement from security folks, since SafeStack doesn't actually sounds too secure any more :("

[harpocrates]

> No they wouldn't. They still need to turn WebAsm/IR into assembly, which is the thing they already do today anyway. Nothing changes for compilers, other than the potential for optimizations gets much, much worse as the IR is comparatively crippled and restricted to the IR they already have.

Most compilers today have separate assembly generation for MIPS, ARM, x86_64. They could turn source into WebAssembly and no more (the job of WebAssembly -> native is left to some other architecture specific compiler).

> This has never been the result of CPU instructions. That's a library problem, not an IR problem. WebAsm does nothing to help with this, particularly as it intentionally has no real standard library to speak of.

If any one language targets WebAssembly, as long as you resolve your libraries within that language, you'll be able to deploy to any target that supports WebAssembly. This is pretty much the defacto solution to the library problem in a variety of ecosystems: in Java you'll make a fatjar and in C/C++/Rust you'll make a staticly linked binary.

> WebAsm is an intermediate, not a source. Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all. That doesn't help you verify anything about your code, which was a compiler, optimizer, and god knows what else away from the webasm that was generated.

Are you familiar with binary analysis?

[andromeduck]

But why use webasm for that when llvm already does it better?

[harpocrates]

I'm not sure I understand: WebAssembly is the output of a (hopefully) optimizing compiler. LLVM is such a compiler backend. If you use WebAssembly today, you are probably going through LLVM.

Perhaps you meant: why not use LLVM IR instead of WebAssembly? If so, allow me to refer you to this comment[1] (from a bit further down in this thread).

[1]: https://news.ycombinator.com/item?id=16586239

[imtringued]

>. Nothing changes for compilers, other than the potential for optimizations gets much, much worse as the IR is comparatively crippled and restricted to the IR they already have.

The performance of an application that doesn't work is worse than a cripple application.

[kodablah]

> I'm so excited about WebAssembly, but really not because of the web.

You and me both. I wrote a backend for the JVM [0] and there is one in dev targetting native [1] (in Rust using an interesting alt-llvm project [2]). I suspect where you'll start to see this really shine is when a popular langauge targets WASM as the primary target and lets second-level backends compile to a specific arch. The other problem is interoperability. Until host bindings come along and the community standardizes on things like string representation and syscalls, many of uses are siloed by the frontend compilers. I think we can do better than libc+posix.

0 - https://github.com/cretz/asmble 1 - https://github.com/sunfishcode/wasmstandalone 2 - https://github.com/Cretonne/cretonne

[fulafel]

This has been tried many times in the history of computing (ANDF/TenDRA, JVM, NaCL, P-code, TIMI, etc). What's different this time?

[lambda]

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.

[narag]

...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.

[harpocrates]

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?

[pjmlp]

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.

[fulafel]

As far as I know, all of them match WebAssembly on those points. Though most are far back in history and not current rivals.

[protomyth]

UCSD p-machine?

[e12e]

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)?

[imtringued]

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.

[AgentME]

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.

[seanmcdirmid]

> 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.

[pjmlp]

There are still quite a few JVM implementations still, they just tend to be specialized in embedded, military or factory automation systems.

[monocasa]

* 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.

[skybrian]

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.

[jcelerier]

> None of them run in a browser

some used to, until browsers banned them

[monocasa]

Because they couldn't get their shit together from a sandboxing perspective.

[zem]

languages are actually eager to target it

[oblio]

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.

[zem]

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.

[jhomedall]

That appears to be an intended future use for WebAssembly: http://webassembly.org/docs/non-web/

[swsieber]

I think this came up recently - I know there's a project to compile webassembly to jvm byte code.

[noahdesu]

We've added Lua scripting into the Ceph distributed object storage system that lets you remotely compute on objects, or create I/O interfaces with new semantics [0]. I've been excited about WebAssembly as a replacement since I learned about it simply because LuaJIT can be a bit of a pain, and because the cross-compiling toolchains already exist that let me get a lot more existing code into a form that can be shipped off to run remotely.

[0]: https://nwat.xyz/blog/2018/03/13/video-of-my-talk-at-lua-wor...

[twoquestions]

And here I thought this entire time that Gary was joking when he predicted this, though I'm glad we didn't have to suffer a war to make this happen.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

[wvenable]

As others have pointed out, platform independent IL is nothing new. There's nothing exciting about WebAssembly outside of the web that hasn't already been done with Java (or countless other technologies).

The true advantage of WebAssembly is that it's so sandboxed that it literally can't do anything on it's own. It can only do something when hosted in a browser where it can use JavaScript to interact with outside world.

[imtringued]

>There's nothing exciting about WebAssembly outside of the web that hasn't already been done with Java (or countless other technologies).

This is completely wrong. The JVM works at an extremely high level. Everything is a garbage collected JVM object. You will never see raw memory at the bytecode layer.

WebAssembly gives you access to the heap and stack at byte granularity. You have to bring your own memory allocator or garbage collector. It's in the damn name: "WebAssembly"

The closest equivalent is NaCL but Google didn't really put a lot of effort into pushing it for wide adoption. If I recall correctly it is also based on LLVM IR and LLVM IR isn't known for maintaining backwards compatibility which turns it into a dead end. Of course if LLVM IR was stable then WebAssembly would be redundant.

We're not living in that world. We're living in a world were WebAssembly is winning not only because of popularity but also because of strong technical fundamentals.

Honestly it seems like HN is blind to fundamentals and everything new is just some hyped up useless piece of shit.

In JS land new = always good. On HN new = always bad. There is no middle ground. Both sides are equally bad.

[wvenable]

> This is completely wrong. The JVM works at an extremely high level.

I'll give you that; it was just one example. There have been plenty of others in history, Pascal P-code is closer to WebAssembly and that's from the 70's! The concept of a portable assembly language is neither new or interesting. WebAssembly is just another compiler target -- if you can compile to it, you can compile to every other native CPU directly. That's just not that interesting as an intermediate form. Java was slightly more interesting as they abstracted the entire platform not just the CPU.

I stand by my statement that WebAssembly is only valuable because it's sandboxed in the browser.

> Honestly it seems like HN is blind to fundamentals and everything new is just some hyped up useless piece of shit.

Maybe being blind to the fundamentals is not knowing the 50 years of technology that has already been done. Remixing old technology in new ways is valuable and in this case remixing portable assembly with the browser sandbox is the cool part.

[colordrops]

I believe EOS (https://eos.io/) uses WebAssembly for non-web applications.

[floorlamp]

DFINITY, Polkadot, and the Ethereum WASM project are other examples of blockchain uses.

[mattcoles]

In what way would it noticeably differ from the LLVM IR then?

[steveklabnik]

LLVM IR is not platform independent, for one. See http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitco... for the projects' own explanation on this topic.

I share the parents' excitement in this regard. The spec is well written for this kind of thing, and I think it has a lot of potential. We'll see!

[andromeduck]

Sounds like JVM

[KMag]

The JVM also forces one to adopt the JVM's high-level object model and use the JVM's garbage collector. Plenty of languages have a large semantic mismatch with Java, and shoehorning them onto the JVM is cumbersome.

[usrusr]

But so far, all those frankenstein hacks still had better interoperability between guest language and java than what you get between the natural peers of js and wasm. It's too early to point fingers that way.

[zaarn]

I think someone in a chatroom I'm in is working on something like this; embed a WASM runtime in a fat ELF (or PE) that will also load a runtime from disk if it's newer and then compile/JIT the included WASM code.

IMO WASM can probably learn from the JVM mistakes a lot, especially when the runtime gets baked in so you don't need it on your computer just to run it (looking hard at you JVM, don't try to hide!)

[earenndil]

People sometimes mention this. What about existing things that do the same? What about the JVM? What about llvm IR and bitcode? What about .net/CLR?

[imtringued]

Well maybe it's because these existing things do completely different things and are completely inadequate?

>What about the JVM? too high level

>What about llvm IR and bitcode? no backwards compatibility

>What about .net/CLR? too high level

What the majority of people here do not comprehend is that if you look at each individual feature (low level, stable) each of them is nothing new. It's the combination of these existing features (low level and stable) that existing technologies are simply not capable of.

LLVM had almost two decades to stabilise their IR and yet they didn't so someone else has to step up and fix what they failed to do.

[ZenPsycho]

you're reminding me of this 30 minute talk from 2014 "the birth and death of javascript", in which he supposes a future where CPUs basically run webassembly directly https://www.destroyallsoftware.com/talks/the-birth-and-death...

[icebraining]

Reminds me of Jazelle[1], which allowed some ARM CPUs to run Java bytecode directly. AFAIK it never really caught on.

[1] https://en.wikipedia.org/wiki/Jazelle

[baobrien]

It also probably didn't help that Jazelle was locked behind an NDA.

[ZenPsycho]

not exactly, the idea is to have a normal cpu like arm or x86 but the kernel doesn't ever deal with native binaries, only web assembly, and the performance penalty of running stuff in a VM gets offset by disabling memory protection and its performance penalty, since memory protection is already guaranteed by the VM.

[austincheney]

> One thing that continues to amaze me is that WebAssembly isn't being discussed more outside of the context of the web.

Probably because WASM is a runtime blackbox locked inside a web page running in a browser. There is a huge amount of overhead to that and the ability to interact with anything external to the blackbox is severely limited.

I get that you are excited that WASM is a compile target for many languages, but it comes with a heavy dose of isolation and performance costs.

[icebraining]

Why is there a huge overhead to that? And how much is "huge"?

[austincheney]

Because a web browser is essentially an operating system running many internal applications. Simply open an empty browser with a single tab and watch how much memory it consumes. Compare that with a new command shell.

[icebraining]

I think harpocrates was talking about running webassembly programs without the browser.

[nerdponx]

Are there Wasm->native compilers yet?

[singularity2001]

node(v8) and all browsers compile Wasm->native ad hoc

[pionar]

I believe the grandparent was talking about machine-language. Take some WASM, produce an EXE, for example.

[KMag]

In this context, "native" and "machine-language" are synonymous, and V8/Node do in fact generate native code/machine-language from WASM. The GP did correctly answer the OP's question, but it's not clear if the OP had a more specific question in mind.

The phrase you're looking for is "Ahead-of-Time" or "AoT" compiler. It's not clear if the OP was specifically looking for an AoT compiler, or if a JIT suffices for her/his use case.

[imtringued]

I don't really think there is any demand for that. The generated WASM code is already optimized. The JIT is basically a very fast AOT compiler. The only advantage you're gaining is faster startup time and that could perhaps be achieved by caching the generated machine code on disk.

[CryZe]

I compiled a GB emulator written in WASM to Rust yesterday and benchmarked it. The Rust one was about 7 times faster.

[sametmax]

Yep. Imagine having a webassembly to python bytecode translator in the stdlib. The possibilities...

[mlindner]

WebAssembly is a dead end. I don't get the hype nor the interest. People tend to forget the huge number of systems out there with tons of active development in C and early versions of C++. Those systems is what Rust would be good for, not "WebAssembly". The vast majority of workhorse code is on the backend, not the front end and UI. I think the only people interested in WebAssembly are former PHP/javascript coders wanting to actually make their code something that runs properly rather than crawls.