Is this correct?
That’s great for compiling languages like C++ or Rust though, but makes compiling higher order langues like python or java to it.
Wasm in many ways is dumb. They could have easily adopted CLR or JVM bytecode. But no, the web is too "cool" for that. It's better to have a brand new VM that's slower and missing GC and a standard library.
Because it has a lower level of abstraction than JVM/CLR (which, for example, have a built-in notion of what an "object" is, and every other language that you compile to it must have its own semantics shoehorned into that), WASM was able to become a good target for C, C++, and Rust.
The ultimate promise of WASM is that (given the right bindings) you can bring any C/C++/Rust codebase into the browser. E.g. see their demo of Doom running in the browser, utilizing WebGL bindings.
[1] https://www.cl.cam.ac.uk/~caw77/papers/mechanising-and-verif..., explainer video https://youtu.be/zsPVbmEPTlA
Many of us consider these points to be features. We don't want a runtime that's as complicated as CLR or JVM bytecode.
> It's better to have a brand new VM that's slower and missing GC and a standard library.
I can understand a desire to build something new and better suited for a particular goal.
Didn't Java execution in the browser(loosely speaking) used to be a thing? I remember that causing security issues, and JVM/Java seems like a large enough thing that trying to mold it into something it isn't seems strange to me.
As for the missing GC, I mostly work with Rust so that doesn't really bother me, although I could see how it would be an issue with other languages. Also, I believe WASI mentioned in the article is the standard library.
https://en.wikipedia.org/wiki/List_of_JVM_languages
WASM needs to move beyond MVP state and get first-class support for DOM APIs in the browser and some kind of first-class OS-agnostic APIs for outside the browser.
Until then I will be stuck with Java and J2cl/Closure (https://github.com/google/j2cl).
That's called WASI
asm.js an extraordinarily optimizable, low-level subset of JavaScript http://asmjs.org/
so, IMO WebAssembly is not a stripped down version of asm.js even if they sold it as that to js devs to foster adoption
Works really really great with Rust.
I doubt it. Like Java, WASM is intended to be used with an optimising JIT compiler. It doesn't make sense to try to implement Java or WASM directly in hardware.
ARM used to offer Jazelle, which could run Java bytecode directly on the CPU. It's now long dead. It makes more sense to use a sophisticated optimising JIT to produce efficient machine-code, than to make hardware to directly run an unoptimised IR.
The BOINC project for distributed computing research uses this method
Do people really want to use such complex, heavyweight languages for scripting?
> WebAssembly enables predictable and stable performance because it doesn’t require garbage collection like the usual options (LUA/JavaScript).
Do garbage collection pauses cause significant issues when embedding Lua or JavaScript? If so, I would expect implementations of those languages to switch to reference counting, but none of them are doing so.
> Extremely fast programs in environments where you can’t JIT for reasons.
To get good performance, don't WebAssembly implementations need to use JIT-compilation internally?
This is a surprising reaction to me, given the history of Javascript and NodeJS in general, but you're not the only person I've seen bring this up.
Ask yourself, 'do people want to use such a strange, high-level language as Javascript for programming servers?' Of course they do, because the primary factor in choosing a language isn't whether or not it's perfectly suited for a specific task, it's how familiar you are with it and how much tooling you already have built up and available around it.
Being able to program your back-end and front-end in the same language is a massive productivity win. It allows you to do all kinds of cool things with architecture and code reuse, and most importantly you don't need to switch mental contexts as often while you're programming.
So if it was reasonable for JS devs to bring their scripting language to the server, it is just as reasonable for Rust/C++ devs to want to bring their server language to the browser. It's not about the language semantics; if someone is primarily familiar with Rust then they'll be faster building web apps in Rust than they would be in Javascript.
> Do people really want to use such complex, heavyweight languages for scripting?
The way I'm reading this, "scripting" should be taken to mean "embedding." Sometimes you do want to run significant amounts of code in a context where traditionally you'd want an embeddable language like Lua or JavaScript, but the fact that such languages are built for scripting (i.e., more optimized for connecting other high-performance components together in a flexible way than for being a high-performance component itself) becomes a limitation.
Some historical examples of where people have wanted complex languages in embedding contexts where scripting languages would have been an easy choice: Google Web Toolkit (write webapps in Java compiled to JS), ActiveX, eBPF, the very idea of loadable native-code modules itself. All of those approaches to the problem have their downsides.
> Do garbage collection pauses cause significant issues when embedding Lua or JavaScript?
Yes, https://www.google.com/search?q=javascript+gc+pause
> If so, I would expect implementations of those languages to switch to reference counting
Reference counting and tracing garbage collection are duals of each other (Bacon et al. 2004, "A Unified Theory of Garbage Collection," which is a great read). You're going to do the same amount of work in both cases if you manage to clean up the same garbage (i.e., if you deal with cycles), it's just a matter of when/how you do it. Technically, yes, reference counting gets you predictable performance (unless you solve the cycle problem with a backup tracing GC), but it may not have the characteristics you want. Knowing in advance that you're going to decref a bunch at an inconvenient time doesn't really help the underlying problem of GC pauses. :)
> To get good performance, don't WebAssembly implementations need to use JIT-compilation internally?
I think only if you are running wasm that changes dynamically / independently of the application, which on at least one "for reasons" platform (iOS) you can't do anyway. If you're willing to ship the wasm with your application, you can AOT-compile it.
No. JITs are great when you're executing code which is very dynamic in nature (either because of dynamic types, or because you're using a lot of interfaces) because the JIT can make use of speculative optimizations based on runtime information.
WASM, however, doesn't really support the notion of compound types and the few types that are supported (int32, int64, float32 and float64) is required to be specified up front. WASM doesn't really have the notion of of ad-hoc polymorphism either. In other words, there's very little for a JIT to speculate about, and so there aren't much insight a JIT can get from having runtime information available. This might change as newer features are added to WASM in the future.
Dynamic languages are great for experimentation and exploring the system, e.g. a console in the browser is the fantastic tool and web dev people tend to try things there first. By embedding wasm, you are making tinkering with the system you provide less enjoyable for your users.
One could argue that since many languages compile to wasm, you can pick whichever suites you best. But in reality, you are probably limited to languages with thin runtimes, e.g. Rust or C. Otherwise you will end up with a huge wasm blob. Imagine, there are 2 Java extensions, a C# one and something in Python, all running simultaneously. It means 3 different runtimes with a footprint by far exceeding that of the application logic in an extension.
Another burden is the bridging between the host and an extension. Unlike lua or js you can’t pass and inspect objects, the only option is to marshal data as a byte blob. So if you were to pick up a language no one used to write extensions for the particular application before, the very first think you have to do is writing marshalers.
Last but not least, I disagree with the article calling S-expressions ugly and strongly believe in the opposite.
Instead of having to distribute a multitude of DLLs for each OS/CPU combination, you only distribute a single WASM module, and the WASM runtime that's integrated into the DCC tool takes care of the platform-specific details. And WASM is also easier to sandbox than DLLs, so a crash in the WASM plugin can't take down the entire application.
In Java, distributing libraries as cross-platform "jars" is very common.
GC is a small part of that - the much bigger factor is dynamic optimization is necessary for fast Lua or JavaScript. Wasm is designed to not need that (like most languages that are not dynamically typed).
Tiered compilation in general does dynamic optimizations, definitely in JavaScript (runtime type collection, etc.) but also to a lesser extent in C# or Java (inlining, etc.). In wasm none of the tiers do dynamic optimizations AFAIK, but tiered compilation definitely helps there too, mostly with startup times.
https://github.com/robot-rumble https://rr-docs.readthedocs.io/en/latest/technical-details.h...
I gave a talk, about a year ago, covering history of the problem statements from which WASM was born and the various forms it is taking.
https://labs.imaginea.com/talk-the-nuts-and-bolts-of-webasse...
Welcome thoughts/comments/corrections/additions.
Next to the mentioned wasmtime, wasm3, and wamr, there is also wasmer[2] I would add to the list of capable WASM runtimes.
The great things these runtimes offer are how easy they are to integrate into other programming languages environments. E.g. with wasmex you could easily run WASM from your elixir application (or with wasmer from ruby[3] or many other languages if you want).
Imagine building shopify, but without needing to invent your own template language for customers to extend their shop-template[4]. They could provide a WASM extension API where shop-owners could let sandboxed WASM files render their shop. This would let allow shop-owners to write templates in their favorite language instead of e.g. liquid and still be secure.
[1] https://github.com/tessi/wasmex/ [2] https://github.com/wasmerio/wasmer [3] https://rubygems.org/gems/wasmer [4] https://github.com/Shopify/liquid
Sandboxed in-game avatar customisation was one of the motivations behind the "WebAssembly Calling Card" (WACC) project I released within the past couple of weeks, posted a Show HN here: https://news.ycombinator.com/item?id=24072304
"WACC: Like an avatar but WASM!"
The WACC specification defines how three 32-bit ints (returned via 3 calls to a function in a WASM module) get turned into triangles:
* 256x256 coord system.
* 15 bit color + 1 bit alpha per vertex triangles.
* 1 FPS!
In part, WACC & the WACC Viewer app is a demonstration of a WIP add-on for the Godot game engine that wraps the libwasmtime WebAssembly runtime so desktop Godot games/apps can call functions in WebAssembly modules. (The other demo app is a tool to help explore `.wasm` files: https://gitlab.com/RancidBacon/wasm-exploder)
The other main goal with WACC is to provide more visually interesting "first run" experiences for people embedding WASM runtimes and/or provide a creative outlet for starting to play around with generating/writing WebAssembly.
So, if you're interested in playing around with some non-browser WASM you might like to have a play with WACC--maybe implement the spec for a different host or create your own Calling Card. (I would particularly like to see it running on standalone hardware like a badge or similar.)
Main site here: https://wacc.rancidbacon.com/
You could use it to just "deploy software anywhere", and that's a neat idea, but it's not 'web' assembly, there's no protections thst make it fit to run arbitrary code from the web.
Download a virtual machine via the app store and then run any app written in any languages and compiled only once.
Almost like JAVA..
