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

91–100 of 178 posts

Re: The Docker+WASM Technical Preview

#91

Post by azakai »

tester756 wrote: post #6

Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close

There has been a large amount of progress on wasm GC actually! If you haven't been attending the group meetings though then you might have missed it. In particular:

* The GC MVP spec is mostly done at this point.

* There are working toolchains for multiple languages: Java, Dart, Kotlin, and others have begun work as well.

* We will have a Phase 3 vote this week.

Re: The Docker+WASM Technical Preview

#92

Post by timanglade »

lolinder wrote: post #89
timanglade wrote: post #61

Earlier quoted context omitted.

"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Comp…

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 part of a microservice architecture). This is particularly helpful if you build apps that have a mix of Wasm & container components[0]

2. Easy way to share & deploy Wasm artifacts, using trusted infra like Docker Hub, but also Dockerfiles and Docker Compose

3. Transparent, reliable way to deploy Wasm applications to existing container-based infrastructure such as k8s (via OCI images) — but these apps can also be “unpacked” to run natively on edge infrastructure

> is it going to wrap the WASM binary produced by cargo in another layer of abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]?

Our approach is close to this. First, it was built with the WasmEdge folks, so you’re correct to detect the similarity. Second, it does wrap resulting artifacts into a OCI image, because we believe that can generate a lot of advantages (points #2 and #3 above) BUT you can also easily unpack the Wasm payload from the binary image at deploytime/runtime if you’d rather deploy your app on Wasm-native infrastructure (as opposed to container-native infra)

Appreciate the feedback. Hope the above helps.

[0]: https://docs.docker.com/desktop/wasm/#running-a-multi-servic...

Re: The Docker+WASM Technical Preview

#95

Post by galangalalgol »

marmada wrote: post #94

How does this work with things like WASI--back when I did WASM things I recalled that WASM relies on imported functions for things like Io, etc. so what functions is the Docker runtime providing here?

I am very confused about how wasi calls work in something like wasmer or wasmtime vs a browser. My guess is the former expose a runtime directly to the wasm executable, and in the browser this has to be done via autogenerated js bindings?

Re: The Docker+WASM Technical Preview

#96

Post by CMCDragonkai »

_mme wrote: post #77
syrusakbary wrote: post #49

Earlier quoted context omitted.

Here are some of the thoughts behind my reasoning that I posted previously in HN. Hope the are insightful! https://news.ycombinator.com/item?id=27158187 https://news.ycombinator.com/item?id=26271806

Thanks, this is interesting, but also very abstract. What do you mean when you say "scaling on the level of a function"? Do you mean any "plain old" function or a specific REST endpoint like AWS Lambda? If you could just throw distributed computing resources at any function that is a bottleneck in your code, that would be alien tech.

It means going in certain directions.

Going from coarse-grained compute to fine-grained compute. The finer grain you have, the more "composability" and "flexibility" you get.

At some point you become so fine-grain that all you have are just lambdas floating in the cloud. And universal pointers to data floating in the cloud. Wire them up and everything scales automatically.

Back when I was working on this sort of stuff, there was an intermediate development between containers and wasm, that being of library OS like mirage OS, unikernels... Etc. I think wasm has probably better positioning compared to those unikernels.

Re: The Docker+WASM Technical Preview

#97

Post by heavyset_go »

timanglade wrote: post #83
stoplying1 wrote: post #67

Earlier quoted context omitted.

This seems like a good way to muddle the remaining value prop that docker has. I have zero idea why I'd want wasm via docker tooling vs what exists, especially as people more more and more to not-docker for building and running their containers. I think I see what someone is trying to do, but I don't know any dev looking for this or having a problem solved by it.

> I don't know any dev looking for this or having a problem solved by it. Judging by the reception at KubeCon & elsewhere today, we think at least some folks are excited by it. But it’s still early, and who knows, you may be right in the end. We launched this as a technical preview to test a hypothesis and learn from it, and so far the interactions from this HN thread alone have been greatly helpful.

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.

Re: The Docker+WASM Technical Preview

#98

Post by _mme »

CMCDragonkai wrote: post #96
_mme wrote: post #77

Earlier quoted context omitted.

Thanks, this is interesting, but also very abstract. What do you mean when you say "scaling on the level of a function"? Do you mean any "plain old" function or a specific REST endpoint like AWS Lambda? If you could just throw distributed computing resources at any function that is a bottleneck in your code, that would be alien tech.

It means going in certain directions. Going from coarse-grained compute to fine-grained compute. The finer grain you have, the more "composability" and "flexibility" you get. At some point you become so fine-grain that all you have are just lambdas floating in the cloud. And universal pointers to data floating in the cloud. Wire them up and everything scales automatically. Back when I was working on this sort of stuf…

So it's a satire?

Re: The Docker+WASM Technical Preview

#99

Post by heavyset_go »

jiggawatts wrote: post #93

This prescient talk "The Birth & Death of JavaScript" by Gary Bernhardt in 2014 is slowly but surely coming true: https://www.destroyallsoftware.com/talks/the-birth-and-death...

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.

Re: The Docker+WASM Technical Preview

#100

Post by dwaite »

AkshatJ27 wrote: post #70

For some reason I thought this was gonna be a demo of running docker in your browser through WASM. kinda disappointed that's not it :p

I think the biggest challenge here is getting the resources through the browser - e.g. enough memory to run a decent container, or the ability to open a listening port.
Post reply on HN