Looks interesting, but why would I need to debug wasm binaries when I could debug directly the rust code? And why would I want to convert it to wasm? In order to run it in the browser, right?
I don't see how you would "debug directly the rust code" without debugging the wasm binaries. Wasm is a compilation target for rust. To be clear: You compile rust directly to wasm, it's not like you compile your rust to a binary and then convert that to wasm. I do not believe there is an intermediate artifact.
As for your second question... there's motion towards making wasm runtimes other environments, like devices or server-side. Kind of like the JVM or CLR, but closer to the metal (e.g. no garbage collector). The advantage of the server-side is the same as node.js, sharing code with the client. The advantage for other environments is a portable file format with performance characteristics closer to native. My impression is that the reception is less enthusiastic than wasm in the browser.
> I don't see how you would "debug directly the rust code"
I think the intention of OP is that you compile the same Rust code to a native x86 or ARM binary and debug that. Most bugs are ISA-agnostic so that approach totally makes sense in many situations.
That's how I'm debugging my WASM code compiled from C/C++, and that also works automatically with IDE debuggers that don't know about WASM (like Xcode's or Visual Studio's).
While that can work with self-contained libs, quite often Rust WASM code uses wasm-bindgen/web-sys to talk to JS/DOM which makes in-browser debugging the only reasonable way.
For bugs that only manifest when compiled to WASM but not when compiled to x86 or ARM machine code (quite rare, but happens), or bugs in platform-specific code (for instance code which talks to browser APIs).
In typical applications, the vast majority of bugs should happen in the platform-agnostic parts, so debugging a native build totally makes sense. It would still be great if WASM would be as trivially debuggable as native code.
IMHO proper source-level debugging support in the browser dev-tools (or remote-debugging via VSCode) would make a lot more sense than debugging in gdb/lldb though.
Mainly because things might work differently in a WASM runtime than they would in native code. A chief example is filesystem access. The WebAssembly System Interface (https://wasi.dev) uses capability-based access to files, so WASM modules are unable to open or write to paths that are not explicitly passed to them, with appropriate permissions, by the WASM runtime.
So there's effectively another layer of sandboxing versus a native binary, and you might need to track down how your program behaves in that sandbox.
Similarly, if you're working with a program that imports several WebAssembly modules, you'll need a way to debug the combined system, versus any single module in isolation.
As for your second question... there's motion towards making wasm runtimes other environments, like devices or server-side. Kind of like the JVM or CLR, but closer to the metal (e.g. no garbage collector). The advantage of the server-side is the same as node.js, sharing code with the client. The advantage for other environments is a portable file format with performance characteristics closer to native. My impression is that the reception is less enthusiastic than wasm in the browser.