alexcrichton

Oh dear sorry about this, it's a little too non-obvious how to see the demo! I've [pushed a small commit](https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bf...) to update the demo to include information about browser requirements. Today this demo requires Firefox Nightly (64) and requires the `javascript.options.shared_memory` feature to be enabled. Other browsers will likely soon be able to run the demo as well!

The futures crate is intended to be the successor to eventual, the author of which, Carl, helped us with some key insights in the futures crate as well.

In Rust it's frequently the case that slow compilations are dominated by generating and optimizing LLVM IR. This codegen step (generating LLVM IR) often takes awhile just because we're generating so much IR.

Rust takes an approach with generic functions called monomorphization which means that we generate a new version of each function for each set of generics it's instantiated with. This means that a future of a String will generate entirely different code from a future of an integer. This allows generics to be a zero cost abstraction because code is optimized as if you had substituted all the generics by hand.

Putting all that together, highly generic programs will generally trend towards higher compile times. With all the generics in play, there tends to be a lot of monomorphization which causes quite a lot of LLVM IR to get generated.

As with many aspects of Rust, however, you have a choice! Rust supports what we call "trait objects" which is a way to take a future and put it behind an allocation with a vtable (virtual dispatch). This forces the compiler to generate code immediately when a trait object is created, rather than down the line when something is monomorphized.

Put another way, you've got control over compile times if you're using futures. If you're taking a future generically and that takes too long to compile, you can instead take a trait object (or quickly convert it to a trait object). This will help cut down on the amount of code getting monomorphized.

So in general futures shouldn't make compilation worse. You'll have a choice between performance (no boxes) and compile times (boxing) occasionally, but that's basically already the case of what happens in Rust today.

You can indeed use this on stable Rust today! Right now 1.9.0 is the minimum supported version due to the usage of `catch_panic` in a few places.

I'd recommend a beta compiler for now though to compile some of the examples. There's a bug in the stable compiler which causes them to take up to 8x longer to compile, but beta/nightly are both speedy!

Excitingly, today! If you run the rustup install script on an arm64 device it should "Just Work", but if it doesn't end up detecting arm64 you can download rustup and/or the compiler manually.

* rustup - https://static.rust-lang.org/rustup/dist/aarch64-unknown-lin...

* rustc+cargo - https://static.rust-lang.org/dist/rust-nightly-aarch64-unkno...

Currently arm64 isn't a Tier 1 platform for us, however, so you may hit some bumps along the way. Please feel free to file issues so we know what to fix if you do!

In addition to not interacting with the GNU toolchain at all (through MinGW), MSVC support will indeed enable native Windows debug info (as you mentioned) so native tools can be used to debug Rust code. Note that this isn't 100% implemented yet, but it's coming soon! Additionally you'll get interoperation with MSVC-compiled libraries. Libraries compiled with MinGW don't interoperate well with MSVC (and vice versa), so this enables Rust code to link against an MSVC-compiled native library.

It does indeed! Due to Rust's lack of a garbage collector or runtime altogether, when C calls into Rust there is no overhead. In the example in the blog post [1] you can see that the Rust function has no extra syntactic burden, and the compiler also will not add any form of conversion one way or another. The C code then just emits a direct call to the symbol, so everything is totally free!

[1]: http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywher...

If you omit the `#[no_mangle]` definition then the compiler will end up emitting a mangled symbol (e.g. one with a long hash at the end that's hard to guess).

Many C APIs take a callback function pointer, which in rust has the type `extern fn()`, and this is the primary use case for an `extern` function defined in Rust which doesn't have `#[no_mangle]` on it.