4 ms·
Not for the time being - to allow us to run code on the edge, and be able to support many customers, we used V8 (a JavaScript engine) since it built for multi-t
by rita3ko 7y ago
Not for the time being - to allow us to run code on the edge, and be able to support many customers, we used V8 (a JavaScript engine) since it built for multi-tenant-per-process secure sandboxing, fast start time, and low overhead (a lot of this is explained in the original blog post here: https://blog.cloudflare.com/introducing-cloudflare-workers/ https://blog.cloudflare.com/introducing-cloudflare-workers/).
We are working on improving our WebAssembly integration, and making it a first-class experience (and we launched multiple improvements with the CLI to allow you to more seamlessly develop in Rust, C and C++). Maybe one day Python WebAssembly will take off.
- fniephaus 7y agoHave you had a look at GraalVM? Their native images [1] allow compilation of JVM-based languages into binaries with fast startup behavior and low memory footprint. [1] https://www.graalvm.org/docs/reference-manual/aot-compilation/ https://www.graalvm.org/docs/reference-manual/aot-compilatio...
- steveklabnik 7y agoGraalVM is really awesome, but it doesn't fit what we're trying to do here. One of the key bits of architecture is that we share the VM between all of the programs; this saves on a lot of overhead. Running multiple native images would still give a copy of each runtime for each thing. (Also, while native images may have low memory footprint themselves, that doesn't mean that the programs that use them have a low enough memory footprint; my understanding (which may be wrong!) is that the default heap size it sets is 80% of the memory of the machine you're compiling it on. You can of course tune that, but it's gonna be tough to squeeze in a memory-hungry application.)