It enables a future world where CPU architecture, OS, and runtime don't matter. Code from any language can run on any hardware and interop with any other code. Cloud hosts can buy whatever hardware is most economical and your code will work there. Just like Docker eliminated a lot of tedious dependency management for deployment, this eliminates another chain of dependencies, but CPU, language runtime, and operating system.

Sun Microsystems would like a word with you.

Yes, you can run anything anywhere as long as it is Java or a JVM language that does not fundamentally change the object or memory management model.

Ha! I didn't say it was a new idea, only that it's the promise :)

As I understand it, WASI doesn't break all security, or at least not by default. Here's a document about capabilities-based design:

https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

You can theoretically run untrusted code from customers in a secure sandbox. This is a simpler proposition that letting customers run vms.

Think “JVM, but better this time”. Better isolation, and more language-agnostic. So, Kubernetes with WASM application servers as an alternative to container runtimes. All the old Java ideas, but hopefully much better. It being originally made for the web has the advantage of it being built with security in mind from the get-go. The JVM was always unsuited for running untrusted code, among other failings.

Wasm is anything but 'secure'.

You should go watch any of the numerous blackhat presentations on wasm or just talk to some of the security researchers out there. You can do attacks that most people haven't been able to do for 20+ years.

Wasm has horrible security.

> You can do attacks that most people haven't been able to do for 20+ years.

This is a bad and roundabout way to say that vulnerabilities in WebAssembly modules may still cause a corruption in their linear memory. Which is absolutely true, but those attacks still matter today (not everyone turns ASLR on) and similar defences also apply. In the future multiple memories [1] should make it much easier to guard against remaining issues. WebAssembly is a lucrative target only because it is so widespread and relatively young, not because it has horrible security (you don't know how the actually horrible security looks like).

[1] https://github.com/WebAssembly/multi-memory/blob/main/propos...

Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.

There are also other things of great value, for example providing a way to write plugins for cloud-based SaaS solutions, as in you compile your binary, hand it over to your SaaS service and the service itself runs your binary when some event happens. Basically plugins for cloud based stuff, much more powerful and simpler than Web Hooks.

Another example was to write custom database functions, for example, adding a complex math function to postgres so you can do "SELECT myFunc(COLUMN_A, COLUMN_B) FROM TABLE".

Another example was to sandbox plugins for desktop applications (including mods for video games), plugins are a huge security issue when it is native code running in your machine.

These plugin examples the entity that is running the plugin code can limit the syscalls used by your WASI-compatible WASM binary so you don't allow, for example, your video game mod to read/write files outside a specific folder in the file-system