For serverless usecases, cloudflare etc.. found that it would be faster to just call a function from a wasm binary than spin up a whole docker container [1]. Which basically translated to cost savings.
In the last company I worked for [2], we saw wasm as a way to easily ship user code in a cross platform way. We mostly targeted edge-ml use cases. Wasm allowed us to package all the "libraries"/functions needed to run the user code securely. So users created and tested out their ML apps in browser and deployed them to all the platforms we supported. (Mobile, Browser, Embedded). As an added bonus they could write each of their functions in any language that compiled to wasm, and just ship it as one "app".
This seems like the best reason to use WebAssembly. The benefit is for the system integrator / platform and the value prop is clear vs. any other technology out there
Great question! The promise (and excitement) of Wasm is to have portable, secure, quick-to-start, and low resource usage apps. So, write code in Go, Rust, C++, or any other language that can output to Wasm (up to over 40 now!) and you're good to go! The binaries are super small too. Happy to dive in more too!
Are there realistic benchmarks that quantify these gains?
A first view of the promise reads reminiscent to the JVM days, which promised to solve portability. The main difference is JIT vs. AOT, but hidden behind that remains also the complex management of FS access, threading, spawning, SIMD, GPU, and other unportable differences. While I imagine that the shim would avoid having a whole Linux, what do we lose in the change?
Why not run that go/rust/etc code natively on the machine though? Is there extra sandboxing, network/filesystem virtualization or anything gained by compiling to and running in a WASM environment?
One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa. So basically you need to build your containers twice if you have macbook people and x86 servers. And technically those are different images, so there's chance that you'll hit some non-trivial difference. With wasm everything could be simpler.
This does not work for me. Java image that takes 30 seconds to build on x86 machine took 40 minutes to build on M1 after which I killed it. So this feature essentially does not exist as it's not usable. I don't think that's how most people use it. I, personally, rent x86 VPS just for docker.
Most images nowadays have ARM version, so probably that's how most people use it.
And it is starting an additional emulated x86/amd64 vm that is emulated. The battery takes a big hit. Now imagine you can run wasm that doesn‘t need an extra vm and doesn‘t drain your battery much faster.
I think the # of people losing a lot of of battery to this is miniscule, especially since the OSX x86 emulation is pretty fast.
A bigger peeve is that there is no general reasonably fast cross build ability, to eg build, test and debug ARM images (for runnign on ARM servers) on x86 Linux or Windows etc.
Gained by you running your app on your own server? not much really.
Gained by some "serverless" provider who tries to run multiple apps like yours, in parallel on the same machine? Yes. Less process overhead. Probably, less memory footprint too.
A majority of software already does this. WASM seems more like a direct attempt to run binary blobs and to simply "trust" the intrusive binary sandbox while leaking all kinds of information when trustworthy sandbox solutions and multi architecture compilation are nothing new and not a new problem that needs solving. It seems if anything the problem people are trying to solve with WASM is how to get people enthusiastic about handing over more privacy.
For serverless usecases, cloudflare etc.. found that it would be faster to just call a function from a wasm binary than spin up a whole docker container [1]. Which basically translated to cost savings.
In the last company I worked for [2], we saw wasm as a way to easily ship user code in a cross platform way. We mostly targeted edge-ml use cases. Wasm allowed us to package all the "libraries"/functions needed to run the user code securely. So users created and tested out their ML apps in browser and deployed them to all the platforms we supported. (Mobile, Browser, Embedded). As an added bonus they could write each of their functions in any language that compiled to wasm, and just ship it as one "app".
1. https://blog.cloudflare.com/cloud-computing-without-containe... 2. https://hotg.dev/