cap-std

I think it's not discussed enough how things like language features shape how library APIs are formed. People usually seem to only consider the question "how would I use this feature?" and not "how would the standard library look like with this feature?", which is surprising given how much builtin libraries affect the pleasantness of a language (OK not that surprising since people usually talk about features added to existing languages that already have a standard library.) One of the things I'm excited to see is the cap-std project for Rust [0] given what Pony [1] has demonstrated is possible with capabilities. I'm also hoping that languages like Koka [2] and multicore OCaml [3] will demonstrate interesting ways to design APIs around algebraic effects. [0] https://github.com/bytecodealliance/cap-std [1] https://www.ponylang.io/discover [

I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level). And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS. But "sanboxing" some process running on a VM is completely independent of that! WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes. If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alter