Maybe a stupid question, but: what is Wasmtime for? What kind of use-cases/applications does it enable and why is this good?
So, no matter how evil, or confused, the program is, you aren't risking your entire system. It's the best part of capability based security.
Capabilities are no Silver Bullet. They work exceptionally well with small teams, but like memory leaks, reachability decisions tend not to scale to very large teams, and people start exposing information for a feature without being able to trace the consequences of having done so.
I could potentially see someone recasting this story as a parable against shared state, but I'm not convinced it's the sole cause or that you could have one without the other. I think it is true that they share a problem space, but that's neither a particularly brave nor illuminating statement.
So I could say, do that again but with a better way to define rules programatically instead of a priori. Multi-tenant, multiple roles, or a Cartesian product of the two sort of demand a little bit of bespoke rules engine work.
It works on web too.
> Back to the future
> For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler.
they should've started with that ;)
I love capability based limits like this (and in Deno), but they’re not a panacea.
This is not just a theory: according to https://hacks.mozilla.org/2021/12/webassembly-and-back-again... Firefox does exactly that trick with five of its C or C++ dependencies.
[1] https://paulbutler.org/2021/calling-webassembly-from-rust/
(nb. if I were to write this post today, it would be an omission not to mention the component model)
They are far from the only implementation, though. You can find links to other runtimes in other comments here already.
My takeaway so far is: it’s a faster, more flexible, and lighter JVM-like thing.
As someone who had written Java Applets from back in the day on the UI side, and written plenty of server side and seen a lot of FaaS successes and failures (more the latter than the former), all the features and use cases map 1:1 - so not really new use cases. Just way better design and implementation (which may make architectures actually end-user usable), w/o money-ed interest.
TL;DR, spicy take: “.class file v2”
Sounds like “far fewer features” to me. Anything that has a lot of features, accumulates a lot if design and implementation compromises (“flaws”)
Is there any benchmarks showing that wasmtime code can run faster than the equivalent JVM code?
How is Wasmtime more flexible than the JVM?
It's definitely lighter, for now, but I am not sure that will always be the case with the many WASM proposals.
Having rust, go, c, c++, being able to be transpiled to wasm byte code is already more flexible than jvm. Why isn’t there a popular C front end to jvm? -> there’s the flex. Also wasm runs in browser w/o loading applets.
Worry about bloat when the project is more mature; there’s no bloat right now and worth exploring.
Actually, wasm is less flexible than the JVM because with GraalVM/Truffle you can run:
1. WASM
2. LLVM bitcode
both on the JVM, alongside all the other languages it can do like Python, Ruby, Clojure, JavaScript, Kotlin, Smalltalk, R etc. Therefore you can run Rust, C and C++ on the JVM. Don't think you can run Go, but this is still way more languages on the JVM than WASM.
https://www.graalvm.org/22.2/reference-manual/llvm/
https://www.graalvm.org/22.2/reference-manual/wasm/
When running these bytecodes on GraalVM, you also get full interop between languages:
https://www.graalvm.org/22.2/reference-manual/polyglot-progr...
You ask why there's no popular C frontend for the JVM. It's because nobody really cares about running C on a VM except for people targeting Chrome/Safari. You can do it with GraalVM and it has some uses for running C language extensions to scripting languages, but otherwise is a bit of a curiousity. Usually if you want to call a C library it's because it's an operating system API or because you want to do things that a VM wouldn't do well anyway e.g. stuff with inline native assembly.
And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things.
However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know.
The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff.
Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).
The real question I think is, if it weren't for particular technical choices by the browser people, would anyone care about JIT compiling C? Probably not. We know how to sandbox C/C++/Rust without a JITC, nacl and other initiatives have proved that. Portability, so what - there's really two CPU archs that matter and new ones don't come along very often. Cross compilers work. The GraalVM guys have found a good reason to JITC of C for language interop and interpreter extensions but that's pretty special case.