Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Docker+WASM Technical Preview

docker.com

Post reply on HN
Print view View original

161–170 of 178 posts

Re: The Docker+WASM Technical Preview

#161

Post by timanglade »

bradgessler wrote: post #158
timanglade wrote: post #153

Earlier quoted context omitted.

AWS announced support for containers on Lambda last year[0] > the "main advantages" [redacted] describes are the same as Docker Yup, that’s it! If you value Docker to build container apps, we think this will help you build Wasm apps in the same way, and the only container-centric abstraction this Technical Preview uses (packaging artifacts as OCI images) can be bypassed, if you prefer to deploy your artifacts as nati…

So the distillation is something like this? "Docker images can now be deployed directly to the WASM runtime! This means your AWS Lambdas, Cloudflare Workers, etc. will boot faster and cost less..." When you rehash what Docker already does, it's watering down the messaging. Even adding "AWS announced support for containers on Lambda last year" in the last reply made the voice in my head ask again, "What's different ab…

That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions rather than full apps, although that is changing quickly.)

What you can however, is build apps for Wasm (or apps that combine Wasm and containers) with the same ease you currently enjoy when building pure container apps, i.e. see my comment above [0]

[0]: https://news.ycombinator.com/item?id=33324093

Re: The Docker+WASM Technical Preview

#162

Post by espadrine »

vbezhenar wrote: post #159
fulafel wrote: post #113

Earlier quoted context omitted.

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

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.

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.

Re: The Docker+WASM Technical Preview

#164

Post by vbezhenar »

espadrine wrote: post #162
vbezhenar wrote: post #159

Earlier quoted context omitted.

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.

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 si…

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.

Re: The Docker+WASM Technical Preview

#165

Post by heavyset_go »

corysama wrote: post #105
heavyset_go wrote: post #99

Earlier quoted context omitted.

I'd love to see this future, but I wonder if a WASM VM can match the performance of something like V8 that is fine-tuned to run a single language well.

That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.

Definitely it is, and it does open doors for this, I'm just curious if running say, a JavaScript or Python interpreter on top of WASM would be more performant than V8, given that there could be two layers of VMs, ie the WASM VM and the JS/Python VM running on it.

I'd hope that they'd be comparable in performance, especially when it comes to doing client-side web app things in languages other than JavaScript.

Re: The Docker+WASM Technical Preview

#166

Post by heavyset_go »

timanglade wrote: post #107
heavyset_go wrote: post #97

Earlier quoted context omitted.

Why were they excited? What use cases does this address? Is the intention to containerize WASM binaries and manage them with Docker like you would any other container? Genuine questions, I'm just trying to understand what this feature is and why someone would want to use it.

I tried to answer this above[0]. Instead of trying to explain it again, I’d encourage you to give it a try[1], and if after going through the 5-minute tutorial you still don’t get the point then a) maybe we messed up (and I’ll be sorry for having wasted your time!) or b) maybe it’s not for you (and I’ll also be sorry I wasted your time). It took me a while to wrap my head around this Docker+Wasm thing too when I firs…

Your second link answered my questions well, thanks.

Re: The Docker+WASM Technical Preview

#167

Post by dmingod666 »

corysama wrote: post #104
timanglade wrote: post #92

Earlier quoted context omitted.

> I'm just sincerely confused at what problem this technical preview is intended to solve. This is all good feedback, and we’ll definitely try to explain the added value better in the future. The main advantages we see in this technical preview are: 1. Easy, reproducible dev environment to quickly & reliably develop cloud/edge apps that target Wasm, or code frontend apps that target a Wasm backend (for example, as pa…

I think you are falling into a “deeply-technical explainer” trap. You’ve been so deeply engrossed in the use-cases of this novel technical combo that they are all assumed understood from your POV. And, this tech is so general that there’s a second trap of “What can it do? It can do anything! Sure, but what can it do??” Again, because I’m your head “anything” is pre-supposed to a narrow set of goals that this tech ful…

I am trying to head around this.

what are the limitations of this? ok, for example can you deploy postgres on the browser with this? can you have a full OS container running on the browser with this, say ubuntu shell frontend with some javascript and an ubuntu container running on the browser?

The first impression from 'Docker + WASM' surely sounds like that is what it is, but after about 30 mins, I am not so sure that is actually the case.

Re: The Docker+WASM Technical Preview

#168

Post by [deleted] »

timanglade wrote: post #161
bradgessler wrote: post #158

Earlier quoted context omitted.

So the distillation is something like this? "Docker images can now be deployed directly to the WASM runtime! This means your AWS Lambdas, Cloudflare Workers, etc. will boot faster and cost less..." When you rehash what Docker already does, it's watering down the messaging. Even adding "AWS announced support for containers on Lambda last year" in the last reply made the voice in my head ask again, "What's different ab…

That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions…

[deleted]

Re: The Docker+WASM Technical Preview

#169

Post by dmingod666 »

mikesir87 wrote: post #156
pmontra wrote: post #141

Earlier quoted context omitted.

So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image and started with docker run instead of (say) an ELF or Windows or Mac binary started with the OS exec, whatever it is? If this is the case I'd leave docker outside the name of the technology. I imagine the confusion. At least one customer of mine doesn't fully get the diff…

> So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image With this preview, we are leveraging the OCI specification that defines how to build an image. Linux/Windows containers are the most common use of this specification, but many other types of artifacts exist (OPA policies, Helm charts, etc.). When using any of these other…

'Docker + WASM' definitely gave me the impression that docker is now leveraging wasm to be able to run your normal container workloads directly on the browser.

Like if you have any docker container, you can now take that, with some modification and run that directly on the browser. Reading further, I think this is totally not what it actually is.

You could say 'Docker for WASM applications' or 'Docker to deploy WASM apps' that would make the relationship more clear I think.

Re: The Docker+WASM Technical Preview

#170

Post by corysama »

heavyset_go wrote: post #165
corysama wrote: post #105

Earlier quoted context omitted.

That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.

Definitely it is, and it does open doors for this, I'm just curious if running say, a JavaScript or Python interpreter on top of WASM would be more performant than V8, given that there could be two layers of VMs, ie the WASM VM and the JS/Python VM running on it. I'd hope that they'd be comparable in performance, especially when it comes to doing client-side web app things in languages other than JavaScript.

That wouldn’t work out. The C Python interpreter is slower than v8. A WASM Python interpreter would be at most as fast as the native C implementation
Post reply on HN