> WASM shares more ideas with CIL than the JVM [..] In WASM the memory management strategy is up to the application.
That level of difference doesn't matter. The point is that WASM is a portable and sandboxed target (like JVM) which is (or will be) faster, more secure (e.g. capability based security in WASI) and with more language support (strictly more when optional GC becomes a thing) and other differences are implementation details.
> Apparently, not all tooling has access to sophisticated language servers; for example, as far as I can tell GitHub source analysis won't be able to find where write_u16 is coming from, and the same is true of Sourcegraph.
FYI, Sourcegraph supports LSIF generated by rust-analyzer. For example, https://sourcegraph.com/github.com/matrix-org/matrix-rust-sd... shows lock method belongs to tokio. It should be able to show origin of write_u16 as well (In the precise mode, not search based).
Gitlab can also consume LSIF, and github should do it someday, IMO, their current way doesn't scale. In most languages you should implement a full compiler front end in order to provide a 100% correct goto definition.
If you disable stuff with `cfg`, you have the ability to give cleaner error outputs. When designing a library to allow choosing between one of two dependencies for an async runtime, I conditionally compiled out all of the crate except for one of two invocations of the `compile_error!` macro (https://doc.rust-lang.org/std/macro.compile_error.html) if either both or neither of the dependencies were enabled, which I think made the experience for users of the library much better compared to having to figure out what was going on from pages and pages of "not found" or "already defined here" errors.
