Hacker News Reader

Comment by corysama | Hacker News Reader

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 fulfills very nicely. It cannot, for example, take my dog for a walk. So, it can’t do “anything” ;p It’s hard to get out of that head-space because you’ve been so deep in it for so so long.

But, I and 85% of people here have no idea what narrow set of goals Docker+Wasm fulfills. Something about apps and security something something. Mostly for servers probably.

Some awesome-fit exemplar use cases would help a lot.

View on HN

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"?

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 native Wasm binaries. The latter can be helpful if you are trying to get the full speed & efficiency benefits of a Wasm-native deployment, as the shim in our OCI package introduces a small performance penalty.

[0]: https://aws.amazon.com/blogs/containers/containerizing-lambd...

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 about it? How is it better?"

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

I think what's missing is why you'd want to do that.

If I have a rust app on a scratch image, why would I want to turn it into a wasm container?

My assumption is because wasm can run on multiple platforms (x86 and arm) so one image supports both, is that correct? Are there other reasons not as obvious?

Assuming you had code that somehow could either be packaged as a linux container, or as a Wasm binary, then the advantage of the latter would be that yes Wasm supports multiple CPU architectures out of the box, it also consumes less resources (memory, etc.), will usually have faster start times, and the Wasm security sandboxing is stronger.

> it also consumes less resources (memory, etc.)

Really? I would not have expected that. Is that just under the assumption that most apps have an underlying OS (like alpine) and aren't on a scratch container?

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.

Reply on news.ycombinator.com