8 ms·

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)

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.

mattcoles 9y ago
In what way would it noticeably differ from the LLVM IR then?
- steveklabnik 9y ago
  LLVM IR is not platform independent, for one. See http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitcode-as-a-binary-format 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 9y ago
    Sounds like JVM
    - KMag 9y ago
      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 9y ago
        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.
fulafel 9y 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?
- harpocrates 9y ago
  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?
  - fulafel 9y ago
    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 9y ago
    UCSD p-machine?
  - e12e 9y ago
    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 9y ago
      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.
  - 9y ago
nerdponx 9y ago
Are there Wasm->native compilers yet?
- singularity2001 9y ago
  node(v8) and all browsers compile Wasm->native ad hoc
  - pionar 9y ago
    I believe the grandparent was talking about machine-language. Take some WASM, produce an EXE, for example.
    - KMag 9y ago
      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 9y ago
      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 9y ago
        I compiled a GB emulator written in WASM to Rust yesterday and benchmarked it. The Rust one was about 7 times faster.
  - deleted 9y ago
    [deleted]
jhomedall 9y ago
That appears to be an intended future use for WebAssembly: http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/
- swsieber 9y ago
  I think this came up recently - I know there's a project to compile webassembly to jvm byte code.
wvenable 9y ago
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 9y ago
  >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 9y ago
    > 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.
twoquestions 9y ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
kodablah 9y ago
> 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 https://github.com/cretz/asmble 1 - https://github.com/sunfishcode/wasmstandalone https://github.com/sunfishcode/wasmstandalone 2 - https://github.com/Cretonne/cretonne https://github.com/Cretonne/cretonne
kllrnohj 9y ago
> 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.
- harpocrates 9y ago
  > 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?
noahdesu 9y ago
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-workshop-2017/ https://nwat.xyz/blog/2018/03/13/video-of-my-talk-at-lua-wor...
colordrops 9y ago
I believe EOS (https://eos.io/ https://eos.io/) uses WebAssembly for non-web applications.
- floorlamp 9y ago
  DFINITY, Polkadot, and the Ethereum WASM project are other examples of blockchain uses.
mlindner 9y ago
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.
austincheney 9y ago
> 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 9y ago
  Why is there a huge overhead to that? And how much is "huge"?
  - austincheney 9y ago
    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 9y ago
      I think harpocrates was talking about running webassembly programs without the browser.
sametmax 9y ago
Yep. Imagine having a webassembly to python bytecode translator in the stdlib. The possibilities...
ZenPsycho 9y ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- icebraining 9y ago
  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 https://en.wikipedia.org/wiki/Jazelle
  - baobrien 9y ago
    It also probably didn't help that Jazelle was locked behind an NDA.
  - ZenPsycho 9y ago
    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.
earenndil 9y ago
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 9y ago
  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.
zaarn 9y ago
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!)

mattcoles 9y ago

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

steveklabnik 9y ago
LLVM IR is not platform independent, for one. See http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitcode-as-a-binary-format 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 9y ago
  Sounds like JVM
  - KMag 9y ago
    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 9y ago
      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.

fulafel 9y 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?

harpocrates 9y ago
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?
- fulafel 9y ago
  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 9y ago
  UCSD p-machine?
- e12e 9y ago
  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 9y ago
    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.
- 9y ago

nerdponx 9y ago

Are there Wasm->native compilers yet?

singularity2001 9y ago
node(v8) and all browsers compile Wasm->native ad hoc
- pionar 9y ago
  I believe the grandparent was talking about machine-language. Take some WASM, produce an EXE, for example.
  - KMag 9y ago
    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 9y ago
    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 9y ago
      I compiled a GB emulator written in WASM to Rust yesterday and benchmarked it. The Rust one was about 7 times faster.
- deleted 9y ago
  [deleted]

jhomedall 9y ago

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

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

wvenable 9y ago

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 9y ago
>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 9y ago
  > 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.

twoquestions 9y ago

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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

kodablah 9y ago

> 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 https://github.com/cretz/asmble 1 - https://github.com/sunfishcode/wasmstandalone https://github.com/sunfishcode/wasmstandalone 2 - https://github.com/Cretonne/cretonne https://github.com/Cretonne/cretonne

kllrnohj 9y ago

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

harpocrates 9y ago
> 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?

noahdesu 9y ago

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-workshop-2017/ https://nwat.xyz/blog/2018/03/13/video-of-my-talk-at-lua-wor...

colordrops 9y ago

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

floorlamp 9y ago
DFINITY, Polkadot, and the Ethereum WASM project are other examples of blockchain uses.

mlindner 9y ago

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.

austincheney 9y ago

> 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 9y ago
Why is there a huge overhead to that? And how much is "huge"?
- austincheney 9y ago
  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 9y ago
    I think harpocrates was talking about running webassembly programs without the browser.

sametmax 9y ago

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

ZenPsycho 9y ago

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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

icebraining 9y ago
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 https://en.wikipedia.org/wiki/Jazelle
- baobrien 9y ago
  It also probably didn't help that Jazelle was locked behind an NDA.
- ZenPsycho 9y ago
  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.

earenndil 9y ago

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 9y ago
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.

zaarn 9y ago

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