@bbatha

Awesome thanks for pointing out the stdweb/cargo-web projects, those are pretty nifty! Mind detailing a bit about what cargo-web is doing? I’m curious if there’s functionality that we may wish to bake directly into Cargo to give it wasm/asm a more “first class” feeling, although starting with a custom subcommand sounds great.

I find the point about general immaturity pretty interesting too. It points that many possible use cases simply aren’t enabled just yet due to lack of APIs, but it’s sort of out of our control. That being said I wouldn’t want that to stop us from providing an as-good-as-it-gets experience today, and that way we can help ensure that most future development on wasm happens in Rust

Could you also elaborate on some of the implementation details of stdweb? 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!

@jimmycuadra

Heh it seems like there’s a very common trend here of “emscripten is a little hard to acquire”! I’ve certainly felt that myself as I can never remember quite what options to flag. AFAIK there’s still a good bit of upstream development needed to get a native compilation target working, but I’d love to see us head towards that as well!

@toolness

FWIW I think https://github.com/rust-lang/cargo/pull/4570 may help quite a bit with these “extraneous files” problems. I think after that we should no longer have weird hashes in filenames and the filename should be deterministic (I think). There may still be a bug or two to shake out though!

I’m perpetually very curious about how Emscripten works with all this, and it certainly soundsl ike you’ve had quite a rodeo with it. I’m personally interested in seeing if we can provide a much more stripped down experience that’s just the bare essentials needed to get Rust working, but that being said I’m not actually sure what such essentials are! It definitely seems like emscripten has a lot of “magic” baked into it, and certainly starting from scratch would lose a lot of that.

@Herschel

To clarify, do you mean interop in the “how do I do it?” kind or the “this just isn’t possible today” kind? In that if we had documentation of how to do it (I’m not so sure how it’s done myself) would that help? Or does wasm/asmjs not support the level of interop needed today?

For example while Rust can interact with C “easily” it tends to be somewhat difficult to do in a robust fashion. Frameworks exist to make this interop much more smooth (and less unsafe), and I’m curious if that’s the sort of tool needed for JS or if we’re waiting on upstream wasm support.

@aidanhs

Oh awesome! I had no idea you were so used to emscripten :). So one question I’d have for you is do you know what an emscripten-less world would look like? How, for example, would the standard library look like? Would you only have libcore? How do things like allocation/printing work? (I’m not even sure how canvases work…)

@newtack

Thanks for the post! Is your project public? I’d love to poke around the slow compile times myself to see what’s going on. If not, do you know if this is rustc’s fault? Or emscripten’s “fault”?

Also I’m curious, if you’re not using emscripten’s runtime, what’s your logic doing? Does it require any resources from the browser, or is it basically just running computations to generate answers?

I’m also personally curious about the bridge between the browser and Rust. Sort of like C and Rust I’d expect it to be a pretty rough experience (aka not beginner-friendly) today, but I’m curious how it’s working for you!

@vvanders

Heh sorry again about the breakage! I agree it’d be best if we got an emscripten builder on Windows running (to ensure that keeps working). I think to me that’d certainly block a “tier 1” status.

Out of curiosity, have you reported any of the debug mode LLVM crashes? I’m sure emscripten and/or us would be quite interested in investigating!

Also when you say it’s painful to build LLVM, do you mean it’d be best to not have to install the emscripten toolchain itself? In that it’d be best (easiest?) to just have rustup manage all toolchain dependencies?

Also, like with many others I’m asking, have you done much Rust/C interop? If so, was doing it in JS “just as hard”, easier, harder?

@gregwtmtno

I’m curious, what sort of C libraries are you using? It sounds like a lot of this thread’s sentiment is to move away from the emscripten runtime, which would sort of move to a “runtime” with no C compiler, so I’m not even sure how pulling in a project written in C would work!

@tomaka

Awesome thanks for pointing out that docker image! I wonder if we could perhaps integrate that with the cross tool to make testing even easier?

Also I’m curious, could you elaborate a bit on the injecting JS? I’m sort of curious just how this all works at the underlying layer. If you’re emitting an asmjs output, does this mean that you basically inject some JS somewhere that’s something you wrote? (in that the final output js file literally contains the textual content of other stuff you wrote). Or does other sort of “linking” need to happen?

If you’re on wasm, what’s being injected? Is that like a shim with which you bridge the JS/wasm boundary? Binding functions in your crate?

(I fear I may not even be knowledgeable enough to know what are the right questoins to ask!)

@rphmeier

Neat! I forget, was that deployed already or still in development? Additionally, do you have any comments (like many others I’m asking) about the JS/Rust bridge? Is it straightforward enough to do, difficult, could be easier, etc?

@LukasKalbertodt

I’m curious, when you say the documentation isn’t that great, was that how to get Rust and wasm/asmjs up and running? Or was that mostly “once I compiled hello world how do I do real things?” For example I’m personally still not sure how I’d create a web page with a wasm module that passes data to Rust, Rust then queries some JS, and then finally returns an answer to the original query. (although I’m sure it’s probably straightforward, just not sure where to look these things up!)

I also wonder, can you quantify the “hugeness” of the emscripten runtime. I tested the other day and a “hello world” rust program compiled to wasm with optimizations was a 93k wasm file. The equivalent C file, however, was compiled to 12k wasm. Is there a threshold for “too large” to bring in?

Also, do know know what a “minimal Rust runtime” would look like? Is that just libstd but with all I/O things returning errors? (but presumably a working allocator?)