Binaries require a container or VM sandboxing in order to run. Java bytecode, afaik, has a slow cold start issue and still requires some additional sandboxing afaik. WASM can cold start fast because the runtime API is natively restrictive to local resources and requires explicit permissions to do otherwise. It would seem that WASM actually makes for a better binary format for edge computing.
Since the WASM runtime doesn't have to worry about resource access violations or memory corruption, it doesn't need a VM or container. This means WASM can start faster without needing any additional security wrappers. I'm doing my best to simplify, but I'd recommend reading about Workerd or Wasmer to learn more about WASM host services.
With all due respect, this doesn’t make any sense. A VM in the JVM sense is an almost identical runtime - why would one start faster than the other? The only difference might be between the speed of the interpreters, as WASM is a bit lower-level than JVM byte code.
Containers have absolutely nothing to do with the topic, and I’m afraid if you mix them up with the former kind of “VM”s your point is moot.
I know little about JVM, but I've gathered that WASM cold starts are far quicker because WASM can be incrementally compiled* as bytes are streamed into edge services. Cold start time is king when almost every user is using a different edge location.
* https://stackoverflow.com/a/58134568
This was a very enlightening thread. My takeaway is: It actually is a similar approach to the jvm, but cold starts faster, whether because of differing design and implementation choices explicitly made to achieve this, or just because it ended up working out that way.
But in either case, "a bytecode for a JIT-compiling runtime that cold starts very quickly", does indeed sound very useful for edge computing. Thanks!
