What is the biggest missing resource for WebAssembly?

Super Mario Odyssey. (I kid, but there's also a deeper truth here; Rust loves to say "X vs Y? We don't choose, the real answer is Z." This is true with things like "Safety vs performance" or "Systems vs usability")

There's lots of great working going on here! Specifically with regards to "pure Rust OpenSSL", https://crates.io/crates/ring is an in-progress, bit-by-bit port of BoringSSL to pure Rust + asm.

I haven't personally run into that need very much, so I can't speak to it directly. The best way to make this change is to get a crate going, prove it popular in the ecosystem, and then make a proposal.

Not literally a gitbook, but we are trying to improve documentation on working on the compiler.

Rust lets you "reach lower" down the stack than Go does, as well as using less memory. There are prominent Node people in both languages; for example, tj moved to Go long ago, and Node shops like npm are deploying Rust today. Finally, it's easier to extend Node with Rust than Go, since Rust has no runtime. https://www.neon-bindings.com/ is a great example of this, and we're working with the Webpack team so that you'll be able to just drop Rust code into your project and have Webpack do its thing, producing webassembly that your Node can use. Finally, it doesn't have to be an either-or: Dropbox is using both Rust and Go where appropriate.

Oh, I forgot: so these differences in approach correspond to how you make that choice: Go is convenient, but comes with drawbacks, such as a non-zero cost to call into C code. Rust gives you much more flexibility and power, but also, that means less ecosystem uniformity. Which one is best for your situation is a question only you can answer for yourself :)

Go bakes in a particular model for network concurrency: you write blocking code, and the runtime does async io for you, switching between goroutines as needed. Rust, on the other hand, does not bake in any particular IO or concurrency model. This means that you have many options; it also means that it's taken us a lot longer to come up with good defaults :) Tokio presents a single-threaded model for non-blocking IO based around futures. But you can also use a lower-level library like mio , writing your own event loop, or you could choose to directly bind to your operating system's IO model. It's up to you. It's the same with concurrency: Rust gives you access to the tools you need to use your platform's threads, or to write your own green threaded runtime on top of them, or use someone else's.

After custom derive landed in 1.15, I lost my good answer to this question ;) I'd say the default binding modes in matches, non-lexical lifetimes, and impl trait. The first one is something I run into all the time, the latter are things others run into all the time.

We've had several projects in this space, and a talk at RustConf last year: https://www.youtube.com/watch?v=lY10kTcM8ek TL;DR: there's some intrepid people working in this space, but it's early days.