This Week in Rust and WebAssembly 10

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Reflecting on Rust and WebAssembly in 2018
wasm-bindgen — how does it work?!
Edge programming with Rust and WebAssembly with Terrarium
Embedding WebAssembly in your Rust Application with wasmer.io
The console_log crate is a backend for the log facade that pipes logged messages to the browser’s console.
Zemeroth is a turn-based hexagonal tactical game written in Rust and WebAssembly.
An example implementation of react/redux style UI development in Rust with percy
Seed is a new Wasm framework for Web apps.
sendilkumarn/generator-wasm-app is a a Wasm app generator for Yeoman.
edvorg/rustsmith is a Rocksmith clone for the Web platform built with Rust and WebAssembly.

`#RustWasm2019` Posts

Rust WebAssembly 2019 by Ryan Levick
My Rust 2019 Dream: Dominate the Web by richardanaya
Wasm 2019 by Yoshua Wuyts
Rust and WebAssembly in 2019 by Nick Fitzgerald
Non-Web Embeddings for Rust Wasm 2019 by Brandon Fish and wasmer.io

Wasm at the 2019 Rust All Hands

The 2019 Rust All Hands meetup was in Berlin on February 4^th through 8^th. @ag_dubs, @alexcrichton, @fitzgen, and @yoshuawuyts from the Rust and WebAssembly working group all made it out to discuss some Wasm-related topics and plan for 2019.

We talked about:

The road to wasm-pack 1.0. This meeting was about trying to pin down what we want to ship as part of a wasm-pack 1.0 release, as well as crystallize wasm-pack’s ideal UX.
A modular toolkit for Wasm. There’s been a lot of talk in #RustWasm2019 posts and the 2019 roadmap RFC about building a modular toolkit for Wasm apps and libraries. This meeting was trying to dig a bit more into the details of what that entails. And naming, of course.
cargo build tasks, hooks, and/or post-build.rs for Wasm. Long-term (likely on the timeline of a couple years) we would like the experience of building Rust and Wasm projects to be exactly the same as building normal Rust projects: just cargo build and that’s it. But there is a bunch of stuff that needs to happen for Wasm after rustc emits a Wasm binary, such as generate JS bindings or run wasm-opt. This meeting was about how to add some sort of generic build hooks to cargo and turn wasm-pack into an implementation of those generic hooks specifically targeted for Wasm development.
Multithreading Wasm and rayon. This meeting was about how we take our experimental Wasm multithreading support and turn it into a reliable library that can serve as the foundation for multithreading on the Web. @CUViper from the rayon team also joined, and we made a plan for how to get rayon working in Wasm.

Updates from `rustwasm/*`

RFCs

New RFCs

2019 Roadmap — this is your chance to help shape our goals for the year!
Add support for local JS snippets in wasm-bindgen

Merged RFCs

None.

Book

@DebugSteven wrote a testing section for the Game of Life tutorial!

Twiggy🌱

We released Twiggy🌱 0.4.0! 🎉
@brson fixed a bug where we would attempt to demangle things that were not C++ symbols as if they were C++ symbols.

`walrus`

walrus is a new library crate for writing Wasm-to-Wasm transformations. It will eventually (but doesn’t yet) preserve DWARF debug info for the Wasm across your transformations.
@alexcrichton got walrus round-tripping all the Wasm spec tests correctly.
@fitzgen wrote a simple Wasm fuzzer, immediately found a bug, and whipped up a fix.
@alexcrichton refactored instruction parsing to avoid recursion. This means that we don’t blow the stack in debug builds or when given malicious input.
We just released walrus 0.1.0 on crates.io — expect more exciting things from walrus in the future :)

`wasm-bindgen`

We released wasm-bindgen 0.2.29 through 0.2.36! 🎉
@derekdreery improved the std::fmt::Debug output for JsValue so that it includes object properties and their values, instead of just [object Object].
@fitzgen made the wasm-bindgen-test testing infrastructure capture more console logging methods’ (warn, info, etc) output for displaying in stdout.
@T5uku5hi added #[allow(clippy::all)] to wasm-bindgen’s macro-generated code, so that running clippy on crates that use wasm-bindgen isn’t so noisy.
@alexcrichton added support for passing Option<MyEnum> back and forth between Wasm and JS if MyEnum has the #[wasm_bindgen] attribute.
@fitzgen added the UnwrapThrowExt trait to wasm-bindgen’s prelude. This extension trait adds unwrap_throw and expect_throw methods to Option<T> and Result<T, E> that have the same behavior as regular unwrap and expect except they throw a JS error on failure instead of panicking. This is morally the same, but ends up avoiding the std::panicking and std::fmt infrastructure, resulting in smaller code sizes.
@alexcrichton migrated wasm-bindgen’s post-rustc Wasm transformations to the new walrus crate! This paves the way for maintaining DWARF debug info through wasm-bindgen.
@fitzgen made the wasm-bindgen-test runtime capture logged messages in tests via textContent instead of innerHTML, avoiding issues when logging HTML strings ;)

`wasm-pack`

We released wasm-pack 0.6.0! 🎉
@drager implemented support for typo detection in wasm-pack’s Cargo.toml section.
@torkve added support for passing arbitrary extra CLI arguments through wasm-pack build and into cargo build. For example, to build with all cargo features enabled: wasm-pack build -- --all-features.
This inspired @chinedufn to add support for passing arbitrary extra CLI arguments through wasm-pack test and into cargo test!
@fitzgen fixed a bug where the output of wasm-pack test was printed twice.
@rhysd added support for emitting the “homepage” field in our generated package.json if it is present in the crate’s Cargo.toml.
@jscheffner fixed wasm-pack’s fetching of chromedriver binaries for headless browser testing on Windows.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

#RustWasm2019 Posts