[vbezhenar]

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]

Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.

[vbezhenar]

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]

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]

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.

[tpetry]

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]

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]

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.

[fulafel]

Ah, TIL.

[DeathArrow]

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.

[phist_mcgee]

So now it's not even just browsers everywhere, it's a binary format for browsers everywhere.