25 ms·

Why WebAssembly is innovative even outside the browser

102 points by abc_tkys 5y ago

andrekandre 5y ago
does wasm support more than 1 program counter (more than 1 virtual cpu?) or is it stuck in "single thread" model? if so, are there any plans to change that?
nomaxx117 5y ago
WASM has far more potential for serverless usage than it does in the browser. I think Cloudflare's Workers are a good example of where things might be going with the tech, but there is room for a lot more. I would love to see something like coroutines adopted for WASM that allow for asynchronous WASM computation.
- flohofwoe 5y ago
  Coroutines are usually a language level construct (syntax sugar for a switch-case statemachine). Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs.
  - nomaxx117 5y ago
    Coroutines are present at the language and runtime level. Most languages with coroutines have runtimes baked in that handle them behind the scenes (think of JS), but some (like Rust) require you to provide your own. Async executors are quite large in terms of code size, so I think it would be useful for WASM to expose a coroutine interface for compilers to target. I think that not having to ship your asynchronous runtime would be very beneficial.
  - DaiPlusPlus 5y ago
    > Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs. Yes and no. Some ISAs do have real "co-instructions" that would be executed concurrently to the "main" program, for example Lisp Machines use this approach for executing bounds-checking concurrently, as well as other kinds of validation/assertions (and even had a limited form of hardware time-travel to jump-back to before a co-processor exception occurred). This approach died out due to the complexity of implementation.
  - rini17 5y ago
    Usually a syntax sugar? Not true, unless you give up ability to call function and switch/resume coroutine seamlessly inside it. You need the ability to manipulate call stack. Regular CPUs have no problem with that but wasm expressly disallows it. So any language with coroutines needs to avoid using wasm stack.
    - flohofwoe 5y ago
      I guess you mean fibers (which require call stack switching). That's one way to implement coroutines, but most languages with async/await implement coroutines differently by transforming async functions into a simple switch-case state machine (where each "yield block" is one case-branch) plus associated local state which doesn't live on the regular call stack. This code transformation is also the reason for "function coloring", which isn't needed for a fiber-based coroutine system.
loxs 5y ago
How easy/practical is it to ship a WASM binary to run on all major platforms?
- ampdepolymerase 5y ago
  You still need a browser if you want to do anything GUI related.
  - edgyquant 5y ago
    You it be faster though? E.g. as a replacement for electron (please note I’ve never worked with electron so I’m using anecdata)
    - imbnwa 5y ago
      If I understand correctly, the consequence is that, Electron being a wrapper around a fully capable browser engine, Electron users are free to use WASM modules so long as they expose a JS interface to interact with Electron's API where neccessary but until WASM gets DOM bindings I presume that Electron itself won't use WASM to implement internal behavior.
  - kitsunesoba 5y ago
    Would it not be adequate to supply a minimal implementation of canvas and develop with a UI framework that draws to canvas? Or perhaps something like React Native, with WASM standing in for the JS runtime?
  - SahAssar 5y ago
    Why? Other languages running in similar environments like Lua/Java don't need a browser. WASM does not need to run within a browser, and there are a couple of runtimes that run it outside of a browser, in that case why wouldn't something like SDL be able to be used?
    - flohofwoe 5y ago
      The most important feature of WASM is that it provides a secure sandbox, and all APIs that talk to the underlying host platforms must be designed with security in mind (see all the considerations that went into WebGL vs vanilla OpenGL).
cxr 5y ago
In many ways, WebAssembly was a poor choice in naming. I propose that "WASM" be retroactively associated with the phrase "world-wide assembly". (Serious proposal. Please consider adopting this in your own usage, even if informally; think of it as guerilla rebranding.)
- flohofwoe 5y ago
  WASM isn't "assembly" either though but bytecode ;)
  - krapp 5y ago
    If we can accept Javascript as bytecode we can accept this as assembly...
    - Grimm1 5y ago
      At the risk of stumbling into something terrible, who accepts Javascript as bytecode?
      - imbnwa 5y ago
        IIRC V8 generates bytecode from the AST and compiles that bytecode
        theta_d 5y ago
        Yes but that is converting JavaScript to bytecode, not using JavaScript as bytecode.
        junon 5y ago
        That's an implementation detail.
      - krapp 5y ago
        Javascript as bytecode (or Javascript as assembly) is a paradigm that comes from compile-to-js languages like Typescript and asm.js[0], considering such "compiled" javascript as equivalent to a universal bytecode. Here's an old HN thread about it [1,2] and if you look around you can find it being asserted[3] as often as criticised[4,5]. Ironically, many of the arguments against the use of JS as bytecode just got transplanted into arguments against WASM, but one common argument against WASM is "why do we need this when we can already compile to javascript?" [0]https://news.ycombinator.com/item?id=5227274 https://news.ycombinator.com/item?id=5227274 [1]https://www.hanselman.com/blog/javascript-is-web-assembly-language-and-thats-ok https://www.hanselman.com/blog/javascript-is-web-assembly-la... [2]https://news.ycombinator.com/item?id=5762183 https://news.ycombinator.com/item?id=5762183 [3]https://news.ycombinator.com/item?id=3708919 https://news.ycombinator.com/item?id=3708919 [4]https://blog.izs.me/2011/09/javascript-is-not-web-assembly/ https://blog.izs.me/2011/09/javascript-is-not-web-assembly/ [5]https://news.ycombinator.com/item?id=5469310 https://news.ycombinator.com/item?id=5469310
CephalopodMD 5y ago
shouldn't the JVM be considered polyglot?
- linkpuff 5y ago
  Uhh, how is it polyglot if it only accepts one language (Java)?
  - neilalexander 5y ago
    It accepts Java bytecode, but various programming languages (Java, Kotlin, Scala, Clojure to name a few) are built on top of that.
  - dkersten 5y ago
    Java, Kotlin, Clojure, Scala, Groovy More here: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages It accepts any language that compiles to JVM bytecode. Java is just one of them. Just like an x86 processor accepts any language that compiles to x86 instructions.
    - linkpuff 5y ago
      Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm can't do. A real polyglot can't only understand a language by requiring it to speak its native language Wasm supports languages that weren't created with wasm in mind, just by requiring a compiler with the right output, without restraining the language.
      - still_grokking 5y ago
        Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
magila 5y ago
With the current state of things WASM is if anything more interesting outside of the browser than in it. Having to shim through JS to interact with browser APIs makes interacting with the outside world sufficiently slow and cumbersome that WASM in the browser usually only makes sense if you have some large computation which requires little-to-no I/O. Outside of the browser you at least have a chance of interacting with the underlying APIs in a performant enough manner to enable a wide variety of applications.
- tasogare 5y ago
  Genuine question: What does it bring new to the table?
  - wtetzner 5y ago
    I think the main thing it brings is a portable compiler target that actually stands a chance at being widely adopted.
  - GranularRecipe 5y ago
    Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! cf https://twitter.com/solomonstre/status/1111004913222324225?lang=en https://twitter.com/solomonstre/status/1111004913222324225?l...
    - junon 5y ago
      This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker. VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface. Further WASI is a nightmare. Most projects I've personally seen disregard it completely.
      - 5y ago
dccoolgai 5y ago
The "grant capabilities" model of WASI is such a "how did they not think of this before?" thing. I need to play around with it some more, but WASMtime, etc. is really fun.
- bryanrasmussen 5y ago
  Capability Computation http://www.erights.org/elib/capability/index.html http://www.erights.org/elib/capability/index.html
- pjmlp 5y ago
  They did, there are several capability based research OSes.
  - naasking 5y ago
    Let's not forget KeyKOS which ran very early ATMs in the 80s!
jokoon 5y ago
Please bring more toolchains to target WASM, and please have some options to interact with the dom!
oblak 5y ago
serious question: what would wide WASM adoption mean for js developers? is my obsolescence imminent?
- AkshitGarg 5y ago
  WebAssembly in the browser currently can't manipulate the DOM directly. Neither can it make HTTP requests. You need to use a JS bridge to do that. That has some overhead. So I don't think webassembly will replace JavaScript anytime soon. It might be reserved for high-performance compute, or maybe canvas based rendering for the time being.
  - runawaybottle 5y ago
    I think the nail in the coffin will only happen when the DOM is killed. If someone can write a rendering engine in WASM that renders to canvas (maybe even render apps with webgl), then can just create a new api for browser apps. That’ll be the end of frontend as we know it, and everyone will have to learn this new api. The benefits are obvious, we’ll finally have a rendering engine for apps. I suppose document-based html pages can stick around, but the rest of us can move on.
    - rini17 5y ago
      And it will be exactly as infuriating as Flash was (except for the artist). Change my mind.
      - pjmlp 5y ago
        I won't surely change your mind, that is exactly what I am looking for. WebAssembly made us regress 10 years, and we lost the great GUI based tooling for Web page creation and 3D games that are actually hardware accelerated without browsers doing blacklists. https://platform.uno/ https://platform.uno/
    - still_grokking 5y ago
      You mean like for example MS Blazor WASM, or Qt for WebAssembly (QML in the browser)? Even I think something like that is long overdue (as the misuse of HTML and DOM as the most horrible GUI framework for application development ever invented should stop immediately) I somehow don't like the outlook of MS Blazor becoming a thing. I hope everybody knows what that would mean: "Windows" (APIs) in the browser… QML on the other hands side looks good (at least from the outside). But it's nowhere close to significant usage, so no hope for that, frankly.
pjmlp 5y ago
Naturally it had to leave out CLR, TIMI, z/OS language environment, BREW, TenDRA, Amsterdam Compiler Toolkit as examples of bytecode formats that support multiple languages, including C and C++. The only innovation is being more marketable.
- brundolf 5y ago
  If history tells us anything, it's that marketability is really important when it comes to getting minimum-viable-adoption for a technology.
  - pjmlp 5y ago
    Specially when most of the audience doesn't bother to go through the standard, or bothers to learn about the history of bytecode formats for executable distribution.
- skybrian 5y ago
  Successfully shipping the runtime in multiple web browsers works pretty well as social proof. People figure that if the sandboxing and portability is good enough for web browser vendors to trust it, it's probably good enough for them. Java rode that train in the early days of the web with applets. But the user experience wasn't good and there were security holes, and Java support was gradually removed. A lot of other languages tried this, but didn't get wide adoption.
  - pjmlp 5y ago
    Secure? "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Other research papers are bound to appear as the security community finally starts looking into WebAssembly security claims. Marketing is everything.
    - Matheus28 5y ago
      I skimmed through the pdf in less than 10 minutes, but from what it seems, it is pointing out how vulnerable binaries compiled to WebAssembly are still vulnerable to exploitation. Well, duh. What WebAssembly protects is the host machine, not the binary running inside the VM. None of these are attacks on the VM itself.
still_grokking 5y ago
How this "comparison" could miss the elephants in the room? Java is mentioned, but not the JVM, or .NET (core)? Therefore this reads once again like an ad… But that actually fits a scheme: Most things one can read currently about WASM are highly over-promising this technology. It's nowhere close to the established VM Runtimes until now! Does WASM really need dishonest marketing posts so badly? Who is actually throwing money after that marketing efforts? Who doesn't like the JVM anymore, and isn't using .NET either?
- pjmlp 5y ago
  It is an ad, most WebAssembly advocates never bother to study the history from bytecode formats since the early 1960s. It sells better when "WebAssembly did it first".
- c-cube 5y ago
  Doesn't the jvm weight dozens of megabytes, with tracing JIT, baked in OO semantics, GCs, etc.? That seems hardly comparable with wasm which currently works best for languages like C++ or rust with pretty small runtime. Just like people more commonly use lua as an extension language rather than Java.
  - still_grokking 5y ago
    And where is the advantage to run C/C++/Rust as WASM? It's much slower than native (you will need a JIT to make it reasonable fast again!), needs a considerably huge runtime with a significant memory overhead compared to native, and a complicated build setup. Someone will say now: Sandbox. But sandboxing native code, in a native way (using directly the facilities that the WASM runtime would use) is much simpler, cheaper, and more performant. And for high-level languages you need anyway all the things that the JVM has build in. Also you get there instrumentation, monitoring, and debugging facilities for "free". The only valid point of criticism I see here is the complaint about the "build in" OO semantics of the JVM. But that's nothing that couldn't be augmented by some better fitting mechanics for cases where translation to OO is very problematic. (But actually I have a hard time to think of an example for this problem. OO and FP are actually duals¹ ² of each other, and there's not much that's neither OO nor FP). ¹ https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf ² https://www.researchgate.net/publication/332248372_Codata_in_Action https://www.researchgate.net/publication/332248372_Codata_in...
ram_rar 5y ago
It sounds great in theory, but I am not convinced that it brings anything significantly new to the table yet. I am still looking for backend applications in wasm outside of envoy proxy. Lua pretty much does everything (minus polyglot) that wasm claims to do and has a good dev tooling system. It ll be a lot more enticing, if I could write lambda functions/serverless computing right of the bat with wasm alone.
DarmokJalad1701 5y ago
Rust has an interesting application for WASM where it can be used to pre-compile macros. Saves a bunch of compilation time by skipping the need to compile the macros up front. https://github.com/dtolnay/watt https://github.com/dtolnay/watt
deleted 5y ago
[deleted]
FounderBurr 5y ago
Say polyglot again.

102 points by abc_tkys 5y ago

does wasm support more than 1 program counter (more than 1 virtual cpu?) or is it stuck in "single thread" model? if so, are there any plans to change that?

nomaxx117 5y ago

WASM has far more potential for serverless usage than it does in the browser. I think Cloudflare's Workers are a good example of where things might be going with the tech, but there is room for a lot more. I would love to see something like coroutines adopted for WASM that allow for asynchronous WASM computation.

flohofwoe 5y ago
Coroutines are usually a language level construct (syntax sugar for a switch-case statemachine). Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs.
- nomaxx117 5y ago
  Coroutines are present at the language and runtime level. Most languages with coroutines have runtimes baked in that handle them behind the scenes (think of JS), but some (like Rust) require you to provide your own. Async executors are quite large in terms of code size, so I think it would be useful for WASM to expose a coroutine interface for compilers to target. I think that not having to ship your asynchronous runtime would be very beneficial.
- DaiPlusPlus 5y ago
  > Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs. Yes and no. Some ISAs do have real "co-instructions" that would be executed concurrently to the "main" program, for example Lisp Machines use this approach for executing bounds-checking concurrently, as well as other kinds of validation/assertions (and even had a limited form of hardware time-travel to jump-back to before a co-processor exception occurred). This approach died out due to the complexity of implementation.
- rini17 5y ago
  Usually a syntax sugar? Not true, unless you give up ability to call function and switch/resume coroutine seamlessly inside it. You need the ability to manipulate call stack. Regular CPUs have no problem with that but wasm expressly disallows it. So any language with coroutines needs to avoid using wasm stack.
  - flohofwoe 5y ago
    I guess you mean fibers (which require call stack switching). That's one way to implement coroutines, but most languages with async/await implement coroutines differently by transforming async functions into a simple switch-case state machine (where each "yield block" is one case-branch) plus associated local state which doesn't live on the regular call stack. This code transformation is also the reason for "function coloring", which isn't needed for a fiber-based coroutine system.

loxs 5y ago

How easy/practical is it to ship a WASM binary to run on all major platforms?

ampdepolymerase 5y ago
You still need a browser if you want to do anything GUI related.
- edgyquant 5y ago
  You it be faster though? E.g. as a replacement for electron (please note I’ve never worked with electron so I’m using anecdata)
  - imbnwa 5y ago
    If I understand correctly, the consequence is that, Electron being a wrapper around a fully capable browser engine, Electron users are free to use WASM modules so long as they expose a JS interface to interact with Electron's API where neccessary but until WASM gets DOM bindings I presume that Electron itself won't use WASM to implement internal behavior.
- kitsunesoba 5y ago
  Would it not be adequate to supply a minimal implementation of canvas and develop with a UI framework that draws to canvas? Or perhaps something like React Native, with WASM standing in for the JS runtime?
- SahAssar 5y ago
  Why? Other languages running in similar environments like Lua/Java don't need a browser. WASM does not need to run within a browser, and there are a couple of runtimes that run it outside of a browser, in that case why wouldn't something like SDL be able to be used?
  - flohofwoe 5y ago
    The most important feature of WASM is that it provides a secure sandbox, and all APIs that talk to the underlying host platforms must be designed with security in mind (see all the considerations that went into WebGL vs vanilla OpenGL).

cxr 5y ago

In many ways, WebAssembly was a poor choice in naming. I propose that "WASM" be retroactively associated with the phrase "world-wide assembly". (Serious proposal. Please consider adopting this in your own usage, even if informally; think of it as guerilla rebranding.)

flohofwoe 5y ago
WASM isn't "assembly" either though but bytecode ;)
- krapp 5y ago
  If we can accept Javascript as bytecode we can accept this as assembly...
  - Grimm1 5y ago
    At the risk of stumbling into something terrible, who accepts Javascript as bytecode?
    - imbnwa 5y ago
      IIRC V8 generates bytecode from the AST and compiles that bytecode
      - theta_d 5y ago
        Yes but that is converting JavaScript to bytecode, not using JavaScript as bytecode.
      - junon 5y ago
        That's an implementation detail.
    - krapp 5y ago
      Javascript as bytecode (or Javascript as assembly) is a paradigm that comes from compile-to-js languages like Typescript and asm.js[0], considering such "compiled" javascript as equivalent to a universal bytecode. Here's an old HN thread about it [1,2] and if you look around you can find it being asserted[3] as often as criticised[4,5]. Ironically, many of the arguments against the use of JS as bytecode just got transplanted into arguments against WASM, but one common argument against WASM is "why do we need this when we can already compile to javascript?" [0]https://news.ycombinator.com/item?id=5227274 https://news.ycombinator.com/item?id=5227274 [1]https://www.hanselman.com/blog/javascript-is-web-assembly-language-and-thats-ok https://www.hanselman.com/blog/javascript-is-web-assembly-la... [2]https://news.ycombinator.com/item?id=5762183 https://news.ycombinator.com/item?id=5762183 [3]https://news.ycombinator.com/item?id=3708919 https://news.ycombinator.com/item?id=3708919 [4]https://blog.izs.me/2011/09/javascript-is-not-web-assembly/ https://blog.izs.me/2011/09/javascript-is-not-web-assembly/ [5]https://news.ycombinator.com/item?id=5469310 https://news.ycombinator.com/item?id=5469310

CephalopodMD 5y ago

shouldn't the JVM be considered polyglot?

linkpuff 5y ago
Uhh, how is it polyglot if it only accepts one language (Java)?
- neilalexander 5y ago
  It accepts Java bytecode, but various programming languages (Java, Kotlin, Scala, Clojure to name a few) are built on top of that.
- dkersten 5y ago
  Java, Kotlin, Clojure, Scala, Groovy More here: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages It accepts any language that compiles to JVM bytecode. Java is just one of them. Just like an x86 processor accepts any language that compiles to x86 instructions.
  - linkpuff 5y ago
    Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm can't do. A real polyglot can't only understand a language by requiring it to speak its native language Wasm supports languages that weren't created with wasm in mind, just by requiring a compiler with the right output, without restraining the language.
    - still_grokking 5y ago
      Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong

magila 5y ago

With the current state of things WASM is if anything more interesting outside of the browser than in it. Having to shim through JS to interact with browser APIs makes interacting with the outside world sufficiently slow and cumbersome that WASM in the browser usually only makes sense if you have some large computation which requires little-to-no I/O. Outside of the browser you at least have a chance of interacting with the underlying APIs in a performant enough manner to enable a wide variety of applications.

tasogare 5y ago
Genuine question: What does it bring new to the table?
- wtetzner 5y ago
  I think the main thing it brings is a portable compiler target that actually stands a chance at being widely adopted.
- GranularRecipe 5y ago
  Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! cf https://twitter.com/solomonstre/status/1111004913222324225?lang=en https://twitter.com/solomonstre/status/1111004913222324225?l...
  - junon 5y ago
    This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker. VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface. Further WASI is a nightmare. Most projects I've personally seen disregard it completely.
    - 5y ago

dccoolgai 5y ago

The "grant capabilities" model of WASI is such a "how did they not think of this before?" thing. I need to play around with it some more, but WASMtime, etc. is really fun.

bryanrasmussen 5y ago
Capability Computation http://www.erights.org/elib/capability/index.html http://www.erights.org/elib/capability/index.html
pjmlp 5y ago
They did, there are several capability based research OSes.
- naasking 5y ago
  Let's not forget KeyKOS which ran very early ATMs in the 80s!

jokoon 5y ago

Please bring more toolchains to target WASM, and please have some options to interact with the dom!

oblak 5y ago

serious question: what would wide WASM adoption mean for js developers? is my obsolescence imminent?

AkshitGarg 5y ago
WebAssembly in the browser currently can't manipulate the DOM directly. Neither can it make HTTP requests. You need to use a JS bridge to do that. That has some overhead. So I don't think webassembly will replace JavaScript anytime soon. It might be reserved for high-performance compute, or maybe canvas based rendering for the time being.
- runawaybottle 5y ago
  I think the nail in the coffin will only happen when the DOM is killed. If someone can write a rendering engine in WASM that renders to canvas (maybe even render apps with webgl), then can just create a new api for browser apps. That’ll be the end of frontend as we know it, and everyone will have to learn this new api. The benefits are obvious, we’ll finally have a rendering engine for apps. I suppose document-based html pages can stick around, but the rest of us can move on.
  - rini17 5y ago
    And it will be exactly as infuriating as Flash was (except for the artist). Change my mind.
    - pjmlp 5y ago
      I won't surely change your mind, that is exactly what I am looking for. WebAssembly made us regress 10 years, and we lost the great GUI based tooling for Web page creation and 3D games that are actually hardware accelerated without browsers doing blacklists. https://platform.uno/ https://platform.uno/
  - still_grokking 5y ago
    You mean like for example MS Blazor WASM, or Qt for WebAssembly (QML in the browser)? Even I think something like that is long overdue (as the misuse of HTML and DOM as the most horrible GUI framework for application development ever invented should stop immediately) I somehow don't like the outlook of MS Blazor becoming a thing. I hope everybody knows what that would mean: "Windows" (APIs) in the browser… QML on the other hands side looks good (at least from the outside). But it's nowhere close to significant usage, so no hope for that, frankly.

pjmlp 5y ago

Naturally it had to leave out CLR, TIMI, z/OS language environment, BREW, TenDRA, Amsterdam Compiler Toolkit as examples of bytecode formats that support multiple languages, including C and C++. The only innovation is being more marketable.

brundolf 5y ago
If history tells us anything, it's that marketability is really important when it comes to getting minimum-viable-adoption for a technology.
- pjmlp 5y ago
  Specially when most of the audience doesn't bother to go through the standard, or bothers to learn about the history of bytecode formats for executable distribution.
skybrian 5y ago
Successfully shipping the runtime in multiple web browsers works pretty well as social proof. People figure that if the sandboxing and portability is good enough for web browser vendors to trust it, it's probably good enough for them. Java rode that train in the early days of the web with applets. But the user experience wasn't good and there were security holes, and Java support was gradually removed. A lot of other languages tried this, but didn't get wide adoption.
- pjmlp 5y ago
  Secure? "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Other research papers are bound to appear as the security community finally starts looking into WebAssembly security claims. Marketing is everything.
  - Matheus28 5y ago
    I skimmed through the pdf in less than 10 minutes, but from what it seems, it is pointing out how vulnerable binaries compiled to WebAssembly are still vulnerable to exploitation. Well, duh. What WebAssembly protects is the host machine, not the binary running inside the VM. None of these are attacks on the VM itself.

still_grokking 5y ago

How this "comparison" could miss the elephants in the room? Java is mentioned, but not the JVM, or .NET (core)? Therefore this reads once again like an ad… But that actually fits a scheme: Most things one can read currently about WASM are highly over-promising this technology. It's nowhere close to the established VM Runtimes until now! Does WASM really need dishonest marketing posts so badly? Who is actually throwing money after that marketing efforts? Who doesn't like the JVM anymore, and isn't using .NET either?

pjmlp 5y ago
It is an ad, most WebAssembly advocates never bother to study the history from bytecode formats since the early 1960s. It sells better when "WebAssembly did it first".
c-cube 5y ago
Doesn't the jvm weight dozens of megabytes, with tracing JIT, baked in OO semantics, GCs, etc.? That seems hardly comparable with wasm which currently works best for languages like C++ or rust with pretty small runtime. Just like people more commonly use lua as an extension language rather than Java.
- still_grokking 5y ago
  And where is the advantage to run C/C++/Rust as WASM? It's much slower than native (you will need a JIT to make it reasonable fast again!), needs a considerably huge runtime with a significant memory overhead compared to native, and a complicated build setup. Someone will say now: Sandbox. But sandboxing native code, in a native way (using directly the facilities that the WASM runtime would use) is much simpler, cheaper, and more performant. And for high-level languages you need anyway all the things that the JVM has build in. Also you get there instrumentation, monitoring, and debugging facilities for "free". The only valid point of criticism I see here is the complaint about the "build in" OO semantics of the JVM. But that's nothing that couldn't be augmented by some better fitting mechanics for cases where translation to OO is very problematic. (But actually I have a hard time to think of an example for this problem. OO and FP are actually duals¹ ² of each other, and there's not much that's neither OO nor FP). ¹ https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf ² https://www.researchgate.net/publication/332248372_Codata_in_Action https://www.researchgate.net/publication/332248372_Codata_in...

ram_rar 5y ago

It sounds great in theory, but I am not convinced that it brings anything significantly new to the table yet. I am still looking for backend applications in wasm outside of envoy proxy. Lua pretty much does everything (minus polyglot) that wasm claims to do and has a good dev tooling system. It ll be a lot more enticing, if I could write lambda functions/serverless computing right of the bat with wasm alone.

DarmokJalad1701 5y ago

Rust has an interesting application for WASM where it can be used to pre-compile macros. Saves a bunch of compilation time by skipping the need to compile the macros up front. https://github.com/dtolnay/watt https://github.com/dtolnay/watt

deleted 5y ago

[deleted]

FounderBurr 5y ago

Say polyglot again.