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

131–140 of 178 posts

Re: The Docker+WASM Technical Preview

#131

Post by fulafel »

tpetry wrote: post #128
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.

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.

Re: The Docker+WASM Technical Preview

#132

Post by mmgutz »

lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

The missing piece. WASM, specificially WASM run time environments, have the potential to replace containers in the future. If you can target WASM with Go, Rust, Python, C, C++ ... then you don't need containers at all.

BTW, the two WASM runtimes jockeying for position are wasmtime and wasmer. It looks like Docker is getting behind wasmtime.

Re: The Docker+WASM Technical Preview

#133

Post by emptysongglass »

timanglade wrote: post #92
lolinder wrote: post #89

Earlier quoted context omitted.

I'm still confused. This is the big thing I'm not really getting: > which allows you to build both traditional container apps, as well as Wasm apps I can already do that. Using Rust for the sake of example: `cargo build` can give me a WASM binary, and `docker build` can give me a container. Is Docker+WASM going to replace `cargo build`? Or is it going to wrap the WASM binary produced by cargo in another layer of abst…

> 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 have some feedback, though more general: can you please stop pushing your flavor of Docker Dev Environments that only works with your proprietary application and get behind the https://containers.dev standard AKA Dev Containers?

You are going to lose this battle because your Dev Environments don't have a lot of buy-in and you're not standardized and open specced. I'd love to see Docker take a more OSS-friendly approach.

Re: The Docker+WASM Technical Preview

#134

Post by politelemon »

mikesir87 wrote: post #122
petilon wrote: post #38

Earlier quoted context omitted.

I didn't get anything from that. My question was not about WASM but Docker+WASM project. Why problem does it solve?

Sorry for the delayed response, but the problem we're trying to help solve is how to help lower the barrier of entry to using Wasm apps leveraging the tool many developers are already using. As an example example, with Docker+Wasm you can use a Dockerfile to build the app in a container image, distribute the Wasm bundle as an OCI artifact, and test it locally using the Wasm runtime. While the ability to build using c…

That does help thanks. It's still all a bit abstract to me because I (like many others) are still not familiar with WASM itself so this next step is probably going to go unappreciated for a while.

I'm a bit surprised by several comments in this post talking about how WASM could replace containers but I don't have the context around it

Re: The Docker+WASM Technical Preview

#135

Post by javaunsafe2019 »

nateabele wrote: post #66
javaunsafe2019 wrote: post #54

Earlier quoted context omitted.

And for just that give up all the freedom docker runtimes give us? I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. And I don’t understand why docker is supporting this as docker + wasm makes no sense at all as wasm wants to replace docker as the runtime provider …

> And for just that give up all the freedom docker runtimes give us? Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples. > I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. Those are runtimes, not languages. Here's a list of langua…

Oh, and I thought that they compile to native code and that therefore the kernel is the runtime …

Re: The Docker+WASM Technical Preview

#136

Post by bradgessler »

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…

What's confusing to me is the "main advantages" Tim describes are the same as Docker, so I'm left wondering what's different about it from Docker? The only thing I can parse out of it that's different is 'apps can also be “unpacked” to run natively on edge infrastructure', but I'm not entirely sure what that means.

My best guess is that Tim is trying to say, "now can run your Docker apps on AWS Lambda"?

Re: The Docker+WASM Technical Preview

#137

Post by bjconlan »

Matthias247 wrote: post #103
lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

I don't really get it either. It's kind of missing which interfaces are actually provided to the WASM script, and how the magic webserver that is described in the docs is working. Most WASI implementation so far seem to just make a stdin and stdout available for a WASM program - which wouldn't really be enough to run a webserver in it. Is this example running a non-wasm webserver that then proxies to WASM modules? Is…

Yeah, I'm with you on this. I'm hoping that there is more to come soon that might flesh out this story. (I mean, surely just having an entrypoint into wasmtime + args or runtime of choice) gets these things inline with existing docker goals.

I think this is mostly a land grab to have docker image repositories be the distribution method of choice for wasi.

Re: The Docker+WASM Technical Preview

#138

Post by code_runner »

My first thought was “what would docker have to do with the client side”… I didn’t realize wasm was running server side these days and apparently with some success?

I wouldn’t have considered running my Java or python on wasm because it’s all server side… that’s just what it does… but the single execution environment with sandboxing is very interesting.

I definitely need a wasm crash course

Re: The Docker+WASM Technical Preview

#139

Post by reubenmorais »

Matthias247 wrote: post #103
lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

I don't really get it either. It's kind of missing which interfaces are actually provided to the WASM script, and how the magic webserver that is described in the docs is working. Most WASI implementation so far seem to just make a stdin and stdout available for a WASM program - which wouldn't really be enough to run a webserver in it. Is this example running a non-wasm webserver that then proxies to WASM modules? Is…

> Is this example running a non-wasm webserver that then proxies to WASM modules? Is that wasmedge? Or does wasmedge really make syscalls like accept() available to the module?

> If it's the latter, how could it actually do something meaningful without threading - given any accept() would block the whole module? Run in non-blocking mode and expect the whole WASM module to be written in async style?

The docs here show how it works: https://wasmedge.org/book/en/write_wasm/rust/networking.html

Re: The Docker+WASM Technical Preview

#140

Post by phist_mcgee »

vbezhenar wrote: post #71
qbasic_forever wrote: post #53

Earlier quoted context omitted.

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.

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