There is one thing that makes WASM very awkward: projecting APIs into a sandbox. If this was done in a way that works in mechanical sympathy with a wide range

There is one thing that makes WASM very awkward: projecting APIs into a sandbox. If this was done in a way that works in mechanical sympathy with a wide range of languages I think WASM would be more successful. Making an API available inside a sandbox is painful. You have to manually roll something that can deal with memory, marshal calls and parameters etc. I'm not suggesting it is easy. I'm merely pointing out that this is what I see as the main obstacle to adoption. I am not interested in "generic" access to system resources (filesystem, network etc) at all. In fact, I can't think of any scenario where I'd actually want to do that. I want to provide APIs that deal with external resources in narrowly defined ways. It is much easier to do this securely when you explicitly have to provide functionality rather than say "here's the filesystem" and then try to clamp down access. I want to use WASM on servers. Primarily in Go. I want to be able to create a bunch of APIs that provide narrow access to persistence and communication and project those APIs into the sandbox. In a manner that is interoperable and easy to use from various languages. I don't want to have to craft some application specific marshalling scheme. If projecting APIs into sandboxes in a (mostly) language agnostic way that is natural, safe and easy to use, it'd be easy enough to write system interfaces. I have no idea why so few people see this as important since I feel it should be self-evident. (And yes, being able to offer concurrency would be nice, but that's a much smaller issue than the problem of there being no good way to marshall APIs into WASM containers)