Hacker News Reader

Comment by ndarilek | Hacker News Reader

Does any of this tooling (I.e. wasm-pack, wasm-bindgen) work with the wasm32-unknown-emscripten target? All of the examples I see use wasm32-unknown-unknown, which is (I think) of limited use to me since I'm linking a fairly complex chain of native libraries against my current wasm target.

It seems like cargo-web has lots of this ground covered already. I'm wondering why build these other tools in that case? I don't have a dog in this fight, I'm just working on a wasm-based app that I'm hoping will serve me for quite some time, and seeing what appears to be duplicated effort at such an early stage worries me a bit.

Either way, thanks for building this!

View on HN

We’re focusing on the unknown target for basically all future work; this stuff can work with the emacripten target, but it might take some PRs to configure it, etc. We’d be open to people hacking on such a thing, but it’s not where the team is putting in any effort.

Got it. I assume the unknown target will never be able to link against native libraries beyond those provided by Rust's core itself? I assume the answer is no, but a few years ago I assumed I wouldn't ever be able to do what wasm is letting me now, so I don't want to hold too tightly to those assumptions. :)

By “native libraries” you mean “C libraries”?

If so, then that’s correct, as rustc can’t compile C code. You need a C -> wasm compiler, and that’s emscripten.

Hopefully we’ll have built the ecosystem enough that you won’t need to rely on those libraries :)

Unless I'm misunderstanding, this sounds like a mistake to me. On any other platform, Rust interoperates smoothly with C libraries and does not demand purity. There's lots of existing code written in C, and expecting all of it to be replaced with pure Rust libraries is unrealistic.

Also, doesn't clang also have a wasm backend now? Emscripten isn't the only option.

It's because this is all a little more complex than that.

Clang does have a wasm backend, same as the unknown target. It suffers the same problems; that is, one of the things that emscripten does is provide a runtime/support code that does things like "automatically translate opengl to webgl". That is, one of emscripten's major goals is "get code that was never assumed to be able to run on the web to run on the web with as little hassle as possible." Outside of the web, those C libraries were very much intended to work on the native platform. So there's extra complexity there.

We continue to support emscripten for when you need this use-case, but it effectively only works if you're building an application, not a library, and we want to support people writing libraries.

Reply on news.ycombinator.com