Hacker News Reader

Comment by remram | Hacker News Reader

Being similar to Kubernetes is nice and makes sense if your audience is familiar with Kubernetes but I can't grasp the advantage over Kubernetes. If you have to run agents on machines and pull artifacts from OCI registries, why not pull containers?

I can see clearly what you lose but not what you gain.

Their entire site seems to be "you want to run WASM apps and we're a great way to do that". But do I want to run WASM apps? Does anyone?

View on HN

These people do https://landscape.cncf.io/?group=wasm

What I'm saying is that running WASM isn't an objective in itself. Just like running containers. Their site should tell me why I want to run WASM because I don't think I do.

Also your page is a list of things that support WASM, not ones that prefer or even value WASM (especially WASM outside the browser...)

Wasm gives lots of benefits and as a project in a new-ish ecosystem we like to tout it and our goals as being a Wasm-native orchestrator. I think in general though nobody should care about running Wasm at all, just like you shouldn't really care about running containers. The goal is to write code and then ship it, the unit of compute is irrelevant. All that being said obviously Wasm isn't a drop-in replacement for containers, but we're working on more and more use cases where you can use them instead. As a developer I don't want to worry about base containers and vulnerabilities outside of my code and cross-compilation and then have to think about Kubernetes of all things at the end of the day

> Wasm gives lots of benefits

Again, such as what?

And if that is true, why aren't some of them listed on the site? Instead of listing the advantages of wasmCloud compared to wasm no-cloud?

We actually used to start with a Wasm-first perspective by focusing on explaining what Wasm is before focusing on our value props. This is good feedback though, we should call these out with more in-depth resources for learning.

To name a few Wasm benefits: - Starts in microseconds, so we scale to zero - Isolation, Wasm can’t reach outside of its memory - Polyglot - Eliminates language silos - Capability-driven security (granular secure-by-default)

Oh man, we have struggled with this- and I wrote the copy under the Build / Compose / Run tab to try and surface what we felt were the most salient points.

For WebAssembly Components- we have tiny, portable code, with a standard ABI that lets us compose between languages. For execution, 50 ns start time means that you can start on demand 'with no cold starts'; the converse is true - scaling to zero.

Because you can scale it and run it only when you need to you can be more reliable (run it in more places) while still operating in a cost efficient way.

It's a subtle story that can be hard to communicate. Thank you for the feedback, we're always trying to do better.

Reply on news.ycombinator.com