7 ms·

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++,

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!

encryptluks2 4y ago
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.
qbasic_forever 4y ago
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?
- saidinesh5 4y ago
  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.
- nequo 4y ago
  AFAIK yes. This interview covers the safety aspects of WASM and you might find it interesting: https://rustacean-station.org/episode/030-krustlet/ https://rustacean-station.org/episode/030-krustlet/
- vbezhenar 4y ago
  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.
  - fulafel 4y ago
    Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.
    - vbezhenar 4y ago
      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.
      - espadrine 4y ago
        I don’t know of any Java compiler to WASM with WASI. The GC model may be a bit experimental for now, since GC is only a phase 2 proposal. Although; do we need a compiler for Java? It may be going full circle. > One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa. That was the advantage given for the JVM. The .jar ran on x86 and ARM. Running raw WASM is similar to running Java bytecode, but with fewer cross-platform APIs.
        vbezhenar 4y ago
        I was talking about ordinary Java projects. Yes, we need a compiler for Java. Java sources are compiled to Java bytecode along with many other actions for complex projects like downloading dependencies, generating sources, running tests which might run platform-dependent binaries and so on. > That was the advantage given for the JVM. The .jar ran on x86 and ARM. Yes, wasm and Java bytecode are the same in that regard. But Java bytecode failed to get adoption outside of Java world. Wasm might not, we will see. One significant improvement of Wasm over Java is good security story. Java sandbox is well known for its CVEs. Browser wasm implementations are battle-tested on billions of devices in the wild Internet. So you basically can't run untrusted Java bytecode without further boundaries like KVM or at least containers. But you definitely can run untrusted Wasm bytecode because that's what your browser does all the time.
espadrine 4y ago
> quick-to-start, and low resource usage 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?

encryptluks2 4y ago

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.

qbasic_forever 4y ago

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?

saidinesh5 4y ago
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.
nequo 4y ago
AFAIK yes. This interview covers the safety aspects of WASM and you might find it interesting: https://rustacean-station.org/episode/030-krustlet/ https://rustacean-station.org/episode/030-krustlet/
vbezhenar 4y ago
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.
- fulafel 4y ago
  Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.
  - vbezhenar 4y ago
    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.
    - espadrine 4y ago
      I don’t know of any Java compiler to WASM with WASI. The GC model may be a bit experimental for now, since GC is only a phase 2 proposal. Although; do we need a compiler for Java? It may be going full circle. > One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa. That was the advantage given for the JVM. The .jar ran on x86 and ARM. Running raw WASM is similar to running Java bytecode, but with fewer cross-platform APIs.
      - vbezhenar 4y ago
        I was talking about ordinary Java projects. Yes, we need a compiler for Java. Java sources are compiled to Java bytecode along with many other actions for complex projects like downloading dependencies, generating sources, running tests which might run platform-dependent binaries and so on. > That was the advantage given for the JVM. The .jar ran on x86 and ARM. Yes, wasm and Java bytecode are the same in that regard. But Java bytecode failed to get adoption outside of Java world. Wasm might not, we will see. One significant improvement of Wasm over Java is good security story. Java sandbox is well known for its CVEs. Browser wasm implementations are battle-tested on billions of devices in the wild Internet. So you basically can't run untrusted Java bytecode without further boundaries like KVM or at least containers. But you definitely can run untrusted Wasm bytecode because that's what your browser does all the time.

espadrine 4y ago

> quick-to-start, and low resource usage 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?