[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.