Writing a core library in Rust --- possibilities for SAFE Browser (WASM)


Cool, I’ve read about that. I assumed because I saw some std::net modules being used in the Tokio code it was dependent on the TCP and UDP mechanisms too.

It’s an educated guess from looking at std implementation for WASM. They contain some stubs and stubs don’t always ‘work’. I’ve seen the amount of dependencies needed for safe_app, it’s a lot! I thought the chance is there at least a few of them use something from std:: that is stubbed (or panics) for WASM. Anyway, I can’t back it up with examples, it may be less worse than I thought looking at the stubs. Threading, syscalls and mutexes(?) won’t run on WASM, I assume — but I have no clue whether those components are used by safe_app or its dependencies.

My point is, the low-level libraries require OS-specific code. I assume WASM isn’t quite yet ready to be a full OS-environment yet, so to me it’s vague on how these low-level libraries translate to that context.

A lot of progress is made on wasm-bindgen, so if it doesn’t work now, it might in a few years. It’s exciting really.

Thanks for that explanation on jemalloc, @hunterlester. The more I read the less I understand.




This gives us portability, because each host can have their own implementation of wasi-core that is specifically written for their platform — from WebAssembly runtimes like Mozilla’s wasmtime and Fastly’s Lucet, to Node, or even the browser.

couldn’t we just compile the c code with clang (target = wasm32-unknown-wasi) and then link it to the rust code (also compiled to wasm+wasi)?