Author of wasmex[1] here (an elixir package which allows runnung WASM).<p>Next to the mentioned wasmtime, wasm3, and wamr, there is also wasmer[2] I would add to the list of capable WASM runtimes.<p>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).<p>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.<p>[1] <a href="https://github.com/tessi/wasmex/" rel="nofollow">https://github.com/tessi/wasmex/</a>
[2] <a href="https://github.com/wasmerio/wasmer" rel="nofollow">https://github.com/wasmerio/wasmer</a>
[3] <a href="https://rubygems.org/gems/wasmer" rel="nofollow">https://rubygems.org/gems/wasmer</a>
[4] <a href="https://github.com/Shopify/liquid" rel="nofollow">https://github.com/Shopify/liquid</a>
One area that I'm hoping WebAssembly will help with is running native extensions in a portable sandbox. That way libraries like nokogiri can be compiled to wasm ahead of time, then executed on a wasm runtime. There will be a perf hit but not having to wait for nokogiri to compile native extensions will be worth it.
Interested to see a number of people mention one of the attractions with WebAssembly being the sandbox &customisation angles.<p>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: <a href="https://news.ycombinator.com/item?id=24072304" rel="nofollow">https://news.ycombinator.com/item?id=24072304</a><p>"WACC: Like an avatar but WASM!"<p>The WACC specification defines how three 32-bit ints (returned via 3 calls to a function in a WASM module) get turned into triangles:<p>* 256x256 coord system.<p>* 15 bit color + 1 bit alpha per vertex triangles.<p>* 1 FPS!<p>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: <a href="https://gitlab.com/RancidBacon/wasm-exploder" rel="nofollow">https://gitlab.com/RancidBacon/wasm-exploder</a>)<p>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.<p>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.)<p>Main site here: <a href="https://wacc.rancidbacon.com/" rel="nofollow">https://wacc.rancidbacon.com/</a>
> <i>This is powerful because you [can] use Rust or C++ as your scripting language.</i><p>Do people really want to use such complex, heavyweight languages for scripting?<p>> <i>WebAssembly enables predictable and stable performance because it doesn’t require garbage collection like the usual options (LUA/JavaScript).</i><p>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.<p>> <i>Extremely fast programs in environments where you can’t JIT for reasons.</i><p>To get good performance, don't WebAssembly implementations need to use JIT-compilation internally?
I doubt that WASM is good as an embedded language, unless performance requirements outweigh the inconvenience.<p>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.<p>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.<p>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.<p>Last but not least, I disagree with the article calling S-expressions ugly and strongly believe in the opposite.
> WebAssembly enables predictable and stable performance because it doesn’t require garbage collection like the usual options (LUA/JavaScript).<p>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).
I'm not sure I understand the use case of the author. He mentions languages (Rust, C++ etc) that can be natively compiled to (almost) any platform, so what's the point of running them in web assembly ? Like Java write once run everywhere ?
Without proper security audits on wasms runtimes they can only be used as hypothetical tools. The main purpose of wasm is a sandbox that's well defined, but that doesn't matter if it's implimentations are vulnerable.<p>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.
There’s a working proof of concept of WASM as a scripting foundation in a WIP programming game called Robot Rumble:<p><a href="https://github.com/robot-rumble" rel="nofollow">https://github.com/robot-rumble</a>
<a href="https://rr-docs.readthedocs.io/en/latest/technical-details.html" rel="nofollow">https://rr-docs.readthedocs.io/en/latest/technical-details.h...</a>
(shameless plug)<p>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.<p><a href="https://labs.imaginea.com/talk-the-nuts-and-bolts-of-webassembly/" rel="nofollow">https://labs.imaginea.com/talk-the-nuts-and-bolts-of-webasse...</a><p>Welcome thoughts/comments/corrections/additions.
I wish things like this could be used to break free from mobile app stores.<p>Download a virtual machine via the app store and then run any app written in any languages and compiled only once.<p>Almost like JAVA..
If you are going to target WebAssembly outside of a browser environment, uh, why not just target LLVM, GNU, or uh, you know, Assembly... X86_64 or ARM are pretty standardized. Another part 1/1 "tutorial" with some brilliant insight as per usual.