4 ms·
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,
by ndarilek 8y ago
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. :)
- steveklabnik 8y agoBy “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 :)
- mwcampbell 8y agoUnless 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.
- steveklabnik 8y agoIt'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.