Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by kaba0 | Hacker News Reader

Parent Full thread

kaba0·

> the runtime API is natively restrictive to local resources

What does it even mean?

View on HN

You can't just go calling fopen with all the permissions of the thread/process.

What does it have to do with fast startups then?

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

Java class files are very small, and also support streamed loading.

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!

Thanks for the mention to Wasmer.

I'll put here a link in case is useful for future readers: https://wasmer.io/

Reply on news.ycombinator.com