[joshum97]

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t been permitted to do.

[qppo]

I dont think it would help at all for compiled languages actually. The reason that they distribute source instead of binaries is mostly due to feature flags and conditional compilation.

Seems a bit off track too. WASM is a very lossy compile target and that's not acceptable for most compiles languages which need explicitness and assumptions about the target machine for their optimizations (ones written by the programmer, not the compiler). And the security concerns are tricky - sand boxing is always expensive.

[johncolanduoni]

WASM’s memory access sandboxing is actually pretty cheap in most implementations; all the major browser engines now use reserved virtual memory with a segfault handler on most systems instead of range checks.

[qppo]

This just cements my belief that the abstraction presented by system allocators is insufficient for modern applications. This shouldn't be done (or necessary) in userspace.

[joshum97]

Good point about conditional compilation. It’s a trade off I’ll leave for language implementors to make. I tend to think that easily preventing a malicious package from sending your file system contents to some server is usually worth 10-20% perf loss, and that might even be made up by Wasm SIMD and other proposals.

[qppo]

Capability based security models should solve that without perf loss, it's just unfortunate they aren't widespread or useful enough yet.

And not to discount your threat model which is a bit hyperbolic, but in applications where you've already making the decision to use a difficult-to-sandbox compiled language, you're not going to have the same justification.

WASM makes a lot of sense for the web where we have mounds of untrusted code, much of which needs to be fast, and is trivial to inadvertently be executed by an unsuspecting user. That's not necessarily true for native applications. The real travesty is the divide between web and native has been so blurred that it's hard to see where it is anymore.

[johncolanduoni]

The packages would have to settle on a stable ABI. This is virtually impossible for Rust (which has no ABI stability between binaries compiled with different compiler versions).

Unfortunately this doesn’t get you much in the way of safety guarantees either, since you can’t readily run these packages in separate WASM instances; Rust, C++, C etc. all assume a shared linear memory when linking.

I’m bullish on WASM in general but I think WASM for simplifying package management or for writing executables that just need restricted filesystem access is a solution in search of a problem. Various containerization efforts have solved most of the important problems here with less runtime and toolchain overhead.

[dmitriid]

> If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them.

Why though? For compiled languages it would make significantly more sense to distribute them in LLVM intermediate representation than WASM.

[joshum97]

I would agree with you, except that LLVM IR isn’t platform independent. For all of Wasm’s warts it’s the best supported low level cross platform IR we have.

[dmitriid]

Well, I'll be! This really is a sad development IMO.

[rkeene2]

The LLVM IR isn't portable. e.g., you can't take the LLVM IR for one CPU or OS and use it on another CPU or OS.

[dmitriid]

Ah, didn't realize it wasn't portable.

[rkeene2]

It makes sense if you think about it -- the front-end that used LLVM to create this IR consumed a whole lot of platform specific information, like the layout of structs, system call numbers, library names, and function names, etc and distilled it to something that knows the results of those things but no longer knows how they were derived, so it couldn't be applied as-is to some other platform.

This is why WebAssembly needs a runtime framework for making things outside WebAssembly accessible to WebAssembly code -- it has to build an abstraction around all kinds of different systems.

It's even worse, though, for LLVM IR, since it targets a specific type of CPU in various ways, where WebAssembly is a single ISA.