State of WebAssembly and Rust?

[lord]

I also was frustrated with Emscripten installation, especially the weird bugs that sometimes crop up on macOS, and so just published the rust-web-inspired wargo for macOS and Linux. It automatically checks dependencies, installs emcc, configures environment variables, fixes some of those weird bugs, and can run Rust tests in real browsers using Sauce Labs or Selenium!

[demurgos]

Hi,

I’ve been looking at using Wasm a few months ago but were not even able to properly install Emscripten. After seeing this post I tried again. First of all, I agree with the messages above: the main pain points for me are the installation of the environment and lack of documentation. I have trouble even running my project so higher level APIs or code size are not a concern for me yet.

My use case is to use Rust to compile a library usable in Javascript, both in Node and the browser.

The Medium post Get Started with Rust, WebAssembly, and Webpack helped me but the Emscripten instructions did not work for me (emcc -v reported errors about fastcomp and a wrong version of clang, it seemed to pick my system clang instead of the one it had built). Even the instructions on the Emscripten website did not seem to be complete. They say to install and activate latest and then configure the environment, but after this step emcc wasn’t even in my PATH (there was no compilation, emscripten wasn’t in the list of installed tools when running emsdk list). I guess that latest referred to the SDK “installer” instead of the actual tools, but it’s confusing.

By mixing the instructions both in the article and Emscripten website, I managed to install Emscripten with:

# Make sure that the `emsdk-portable` directory is in the $PATH before running these commands
emsdk update
emsdk install latest
emsdk activate latest
emsdk install sdk-incoming-64bit
# Activate was missing in the article
emsdk activate sdk-incoming-64bit
# This command was also missing, not sure if it's needed, it seems to just set the env variable `EMSDK`
source emsdk_env.sh

Once this was configured, I was able to compile and run the Hello world exemple of the article as well as the Wargo loader example (it’s almost the same thing).

Starting from there, I wanted to experiment with building a small library. My goal is to port my SWF parser. I have both a Typescript and Rust implementation, I’d like to use my Rust implementation in Node or the browser using Wasm, with the same API as the Typescript version. Basically, I want to learn how write a library able to swap a JS implementation for a Wasm implementation and not break its public interface. In my example, I’d just like to start with a JS interface exposing a single async function parse that takes an ArrayBuffer and returns a JSON string representing the AST. I’d expect it to be not too hard but have no idea how to do it: it seems just a level above the add function in the hello-world example. I am not using any system dependant features, the API only uses buffers and strings.

Here are the questions I have regarding this sort of project, the Medium (and others) example and Wasm in general.

1. How do I build a Wasm library? I just want a lib.rs instead of a main.rs.

   If I rename main.rs, remove the main function and update "index.js", cargo does not even compile any js file. cargo build --target=wasm32-unknown-emscripten does not even produce a .wasm or .js file. This is maybe related to this issue.

   A pattern I’ve seen on a few websites is to use a main.rs but with an empty main function and the other public functions in this file. This seems like a hack but at least it allows me to expose functions. Still, when running it in my browser I get a warning:

   exit(0) implicitly called by end of main(), but noExitRuntime, so not exiting the runtime (you can use emscripten_force_exit, if you want to force a true shutdown)
   

   This seems caused by {noExitRuntime: true} but there’s no explanation about this option. If I remove it, it crashes. Does main has to run to invoke the other exported functions?

2. What does the webpack’s loader do? How can I use wasm without it? How can I use wasm in Node?

   Why does Webpack runs the cargo compilation? Can’t I compile my project to wasm beforehand and then use const wasm = require("./my_lib.wasm")? I know that it needs a JS glue for the conversions, but can’t it just let me import the .wasm files and inject the glue automatically? What if I have multiple Wasm modules? Do I need a JS wrapper for each wasm file? Is it possible to load a Wasm file manually without the JS wrapper? I’ve seen WebAssembly.instantiate and new WebAssembly.Module on MDN but it’s lacking complete examples. What does the importer argument for WebAssembly.Module even do? How do I import a Wasm module in Node, do I still need Webpack?

3. How to structure my code?

   In my ideal world, I would like to publish my library to npm and let others use it without even knowing that it uses Wasm. Did somebody ever do this? How do you add a fallback to asm.js? Does it play well with bundlers used by the consumers of the library? Are there some gotchas when designing the JS API such as memory leaks or initialization that must be done by the consumer? What about module formats, commonJs and ES2015 modules?

4. How do I maintain Typescript definitions? Typescript is a god-send for JS. Is it possible to emit type definitions for Wasm modules? @CryZe mentioned that some autogeneration is possible. Are there some examples? Is there some documentation?

I don’t expect answers for all these questions. I just wrote them down so you can get an idea of what kind of problems I encounter as a newcomer to Wasm. I really miss an official source documenting how to use Rust for Wasm. I feel as if all we have to work with are some hello-world examples spread accross the internet. A Github repo with a book and examples that could be maintained by the community would be great.

[gilescope]

Hello world went well once emscriptem compiled, but for me, rust In webassemblies can’t really shine until we can use multiple threads. That’s rust’s killer feature, and bringing it to the web will be awesome.

[rphmeier]

Yep, the two things I mentioned there are live. We spoke at RustFest about parity-wasm which is semi-related: the WASM interpreter is functional, although still WIP. Minimal examples of smart contracts written in Rust seem to work, although we haven’t yet tried much more complicated.

[NikVolf]

Adding a bit here:

Using Rust to compile to WebAssembly is still not completely usable in our applications in Parity.

Runtime is just huge, most of it is not used by actual code we want to run sandboxed and it is not being optimized out from binary. I can compile C source to just 120 bytes (!) of WASM with emcc, no way to do the same in Rust. Maybe using emcc SIDE_MODULES and compiling crates as side modules can somehow help.

This probably due to no dynamic linking and no library building support at all. If I just want to make sandboxed pub fn add(a: u32, b: u32) -> u32 in Rust usable from whatever can run WASM, i will still get WASM as the result which has main function, which will import various runtime symbols like STACK_TOP, DYNAMICTOP_PTR etc. (never used by actual code i care about - add function). Can be done easy with emcc and C.

We do a little tree-shaking against, say, add function (just exclude everything that can not be possible invoked from add including imports, globals, other functions and everything), but much of the runtime compiled into dynamic calls via call_indirect and cannot be statically optimized.

Despite those difficulties, we still have a lot of code that compiles to a rather performant wasm: keccak/sha256 hashing, secp256k1 cryptography, big (256/512) integer arithmetic, and we hope to make Rust suitable choice for smart contract development

[demurgos]

@NikVolf

Is the source code for the tree-shaking or the projects you mentioned (hashes, big integers) available somewhere?

[NikVolf]

source is here

paritytech/wasm-utils/blob/master/src/optimizer.rs

and also available as command line util

cargo install --git https://github.com/paritytech/wasm-utils wasm-prune

[alex-shapiro]

Just adding another data point:

I’m compiling Rust to asmjs and have attempted to compile it to WebAssembly. My use case is a cross-platform library integrated into a larger JavaScript codebase. I haven’t had any issues installing, compiling, or linking, but I’ve run into some general problems and frustrations:

• FFI is high-effort because it requires two explicit interfaces, one between JS and C and another between C and Rust. For instance, any function that passes a string to Rust has to convert JS string -> cstring -> &str and then free the cstring from the heap once the Rust function returns. Returning a string from Rust requires the same process in reverse. cwrap removes the JS <-> C FFI but it causes memory leaks in functions that return cstrings because it frees the cstring with free rather than Drop.
• Both asm.js and wasm have huge starting file sizes, I guess because of libc. My use case only requires libc for heap allocations.
• I can’t figure out how to use asmjs or wasm with WebPack. There’s at least one solution on GitHub but I couldn’t replicate it.

[koute]

Author of stdweb and cargo-web here. AMA.

Could you also elaborate on some of the implementation details of stdweb?

As it was already mentioned, stdweb mostly uses emscripten_asm_const_int, etc. to embed JS code into Rust, and it has a fairly extensive machinery to marshal data between Rust and JS.

Glossing over some implementation details the js! macro goes through the tokens it was passed twice - in the first pass it stringifies everything, so

js!{ alert("Hello world!" + @{123}); }

becomes (minus some extra whitespace):

const CODE_STR: &'static str = "alert(\"Hello world\" + $0);\0"`;
const CODE: *const u8 = CODE_STR as *const _ as *const u8;

In the second pass it looks for any @{$expr} where $expr is a Rust expression, and automatically serializes them. Something like this is emitted (I’m simplifying so not exactly, but it’s just so that you get the idea of how it works):

let a0 = $expr;
let a0 = serialize(a0, arena);
let a0 = &a0 as *const _;

Then it finally calls into emscripten:

emscripten_asm_const_int(CODE, a0);

(Not shown here is handling of a return value, and all of the other machinery necessary for serialization.)

Are there various features we need to add to rustc to get things to work? Maybe work nicer and/or less brittle than they may be right no? I’m not even sure how a js! macro would work!

@alexcrichton Some of the features off the top of my head that I would like the compiler and/or cargo to have, in no particular order:

• Fixing cargo #2508 or any of the related issues. (Basically add an easy way to get the path to whatever cargo generated.) Yes, I know I can use --message-format=json, and no - I don’t want to. I just want to run cargo, pipe all of the messages back to the user, grab the path to whatever file was generated and do something with it.
• Stable procedural macros. Currently the js! macro is one, big, ugly hack, with ridiculously long compile times.
• Procedural macros which do not tokenize the input and pass the input string exactly as it appears in the source code, e.g. the procedural macro is passed code: &str, filename: &str, line: u32, column: u32. Then we can use a full JavaScript parser on code, and easily report any errors since we know the first character from code is at filename:line:column.
• The ability to use a custom test harness, or even a predefined harness which would support asynchronous code. Currently (AFAIK, please correct me if I’m wrong) it’s not possible to test anything which is asynchronous. In native code this isn’t really a problem since you can just block until the thing you’re testing finishes, but you can’t really do that here. For example, what I’d like is to be able to do something like this (to test setTimeout):

#[test]
fn test_set_timeout(done: Box<FnOnce(Result<(), Box<Error>>)>) {
    stdweb::set_timeout(|| { done(Ok()); }, 1);
}

• Have cargo install Emscripten automatically so that I don’t have to. I have some bastardized Docker build scripts to build Emscripten for Linux, but it’s a pain to maintain and since I don’t have the infrastructure I’m unable to provide packages for all of the platforms.
• A way to easily mark a function to be exported to JS, and a way to process such functions at compile time so that the marshaling machinery can be automatically generated for them. (I haven’t thought about this too much yet, so I’m not really sure yet how exactly it would work; just throwing it out there. This could probably be done with procedural macros, and a tiny bit of supporting code in the compiler which would export the symbol to the JS world.)

[bstrie]

Inlining this comment from HN: https://news.ycombinator.com/item?id=15530104

Hi, I’ve been using Rust to WebAssembly very recently for a toy project [0] and posted about it very recently on HN [1].

So my answers:

1. I’m using both wasm and asm.js (installed using rustup) and it works for me extremely well, no weird bugs, very easy to set up.

   However I’m really missing a way to pass arguments to the linker, like “-s BINARYEN_METHOD=‘asmjs,native-wasm’” or “-s EMCC_DEBUG=1” or “-s DETERMINISTIC=1” or “-s SIMD=1” or “SIDE_MODULE=1”

   I think there is already a bug opened for this but I’m not able to find it on Google right now.

   From crate.io, I’m missing a N-dimensional array library (BLAS/LAPACK like) that compile to webassembly. There is ndarray[3], but its available BLAS dependencies are using fortran and therefore not compilable to wasm. Maybe thoses projects could help: emlapack[4], weblas[5]

   Also, I know it would be difficult to implement and would need some kind of better interaction with emscripten, but anything that makes it easier to pass and convert/cast object/arguments to and from javascript would be welcome. Right now, it requires a lot of boilerplate and unsafe code, mostly with structs [6].

2. I’m using it and considers using it more, I love it, thank a lot to everyone working on it!

3. Right now I’m deep into deep learning and I’m thinking about writting an implementation in Rust (that’s why it would be nice to have a BLAS/LAPACK library). It could then be used on the Tensorflow playground[6] to showcase the technology.

[0] https://buddhabrot.paulg.fr

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

[3] https://crates.io/crates/ndarray

[4] https://github.com/likr/emlapack

[5] https://www.npmjs.com/package/weblas

[6] https://github.com/PaulGrandperrin/rustybrot-web/blob/master…

[7] http://playground.tensorflow.org

[gus]

It’s not at all related to Rust, but just for completeness I once implemented a radically different approach to emscripten for running compiled code in-browser. My main challenge was implementing the correct blocking/synchronous behaviour inside a browser, so I ended up writing an LLVM bitcode (*.bc) interpreter in javascript. Supports pre-emptive threading and a simple method-JIT that does something like emscripten-on-the-fly for functions that are called frequently and the VM can prove don’t block.

Here it is running ScummVM (a 20k-line highly portable C++ project), using only the existing ScummVM platform portability abstractions (implement file accesses as URL fetches, convert drawing primitives into canvas calls, etc).

I haven’t touched the code in many years, so it needs to be updated to the latest LLVM bitcode format (not something I’m looking forward to), it was written pre-wasm/asm.js, and I never really did much towards optimisation.

But my point was: I found this interpreted approach easier for porting codebases expecting a vastly different runtime model than the straight-to-javascript approach of emscripten, and with acceptable speed. Just food for thought.

[alexander-irbis]

However I’m really missing a way to pass arguments to the linker, like “-s BINARYEN_METHOD=‘asmjs,native-wasm’” or “-s EMCC_DEBUG=1” or “-s DETERMINISTIC=1” or “-s SIMD=1” or “SIDE_MODULE=1”

#![feature(link_args)]
#[cfg_attr(target_arch="wasm32", link_args = "\
    -s TOTAL_MEMORY=268435456 \
    -s NO_EXIT_RUNTIME=1 \
")]
extern {}

[aidanhs]

My main challenge was implementing the correct blocking/synchronous behaviour inside a browser, so I ended up writing an LLVM bitcode (*.bc) interpreter in javascript. Supports pre-emptive threading and a simple method-JIT that does something like emscripten-on-the-fly for functions that are called frequently and the VM can prove don’t block.

This sounds similar to the Emterpreter, except yours uses LLVM bitcode directly whereas the Emterpreter goes all the way to asm.js and then translates that into a bytecode (plus generates an interpreter). It’s a great option for easily porting blocking behaviour, and also supports calling into asm.js code for perf-critical parts. This makes yours an interesting trade-off - while it sacrifices performance initially, yours don’t require a user to list the functions they want (or don’t want) to be Emterpreted, they’re just jitted if appropriate.

I’m curious - do you have any feel for how much slower your interpreter was than native? asm.js is commonly seen as 2x slower than native, and the Emterpreter is ~10x slower than that. Given that the Emterpreter translates from asm.js, it should be benefiting somewhat from the asm.js optimizer passes happening beforehand (e.g. register allocation), plus the interpreter itself being generated asm.js code.

[steveklabnik]

Related, one thing we need big improvement on here is docs; see this thread on users:

Simple Rust WebAssembly Tutorial Request

(Plus if anyone from this thread has good resources, go help them out! :D)

[konstin]

@koute Re AMA: What’s the current state of stdweb and wasm? I’ve seen this unanswered issue, which says that at least one example works, though all my attempts to use stdweb with wasm failed.

[gus]

I’m curious - do you have any feel for how much slower your interpreter was than native?

A lot slower than compiled to native executable code (ie: no javascript). I was effectively emulating a 16MB RAM i486 at faster-than-realtime on a “decent laptop” circa 10y ago. I’d guess wildly that that’s about 10-20x slower than running the same code compiled straight to amd64 executable. I have no idea how that compares to wasm/asmjs, since they didn’t exist in more than blog-manifesto-form at the time.

Also: I did relatively little optimisation, other than using the javascript minimiser (which inlined trivial js function calls). My jit-generated javascript code was a naive translation of llvm basic blocks (each function was a loop over a switch(block_number) block - so I could do jumps between blocks), and I know emscripten moved on from that to (presumably) much faster constructs early in emscripten’s history.

[koute]

@koute Re AMA: What’s the current state of stdweb and wasm? I’ve seen this unanswered issue, which says that at least one example works, though all my attempts to use stdweb with wasm failed.

@konstin It should work. Install newest cargo-web (updated today), clone stdweb, go into examples/todomvc, type cargo web start --target-webasm-emscripten and visit http://localhost:8000. (With a caveat that cargo-web will take care of the Emscripten stuff for you only if you’re running Linux; on any other OS you’ll have to install Emscripten and Binaryen yourself.)

[djc]

Just to make sure no one on this thread misses it, Alex has been working on a new wasm target:

std: Add a new wasm32-unknown-unknown target

[NohatCoder]

Is it correct that there is no safe way to persist data between calls from JavaScript?

In a normal Rust program one can allocate some data structures in main, and pass them around as needed. But with a wasm target there is no persistent function, thus everything allocated normally will be cleaned up when returning the call from JavaScript.

It seems weird that I should have to resort to “unsafe” for such a simple and basic feature.

[CryZe]

You can solve this by returning all the long living state to the JavaScript code that then manages it. You can do that by passing an opaque heap allocated pointer to javascript, that it can then pass back into the functions that need to access it. You can create such an opaque heap allocated pointer by using Box::into_raw(Box::new(obj)). Whenever JavaScript doesn’t need the data anymore, you also need to provide a free_my_opaque_ptr function that takes that opaque pointer and turns it back into a Box that then gets dropped Box::from_raw(ptr). Unfortunately there’s no way to tell JavaScript to automatically call that free function whenever the corresponding variable in JavaScript goes out of scope, so you are now in manual memory management mode in JS.