4 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?
- 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/
- 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.
- 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.
  - DeathArrow 4y ago
    Building and deploying is most often the job of the pipeline so the arm debug build from the developer desktop won't be run on the X86 server.
  - fulafel 4y ago
    Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.
    - tpetry 4y ago
      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.
      - fulafel 4y ago
        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.
        vbezhenar 4y ago
        There's no OSX x86 emulation. There's Rosetta emulation and qemu emulation. Rosetta emulation is quite fast. But docker does not use it. At least for now. qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.
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?

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/
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.
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.
- DeathArrow 4y ago
  Building and deploying is most often the job of the pipeline so the arm debug build from the developer desktop won't be run on the X86 server.
- fulafel 4y ago
  Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.
  - tpetry 4y ago
    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.
    - fulafel 4y ago
      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.
      - vbezhenar 4y ago
        There's no OSX x86 emulation. There's Rosetta emulation and qemu emulation. Rosetta emulation is quite fast. But docker does not use it. At least for now. qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.

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?