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

WASM will replace containers

creston.blog

Post reply on HN
Print view View original

301–310 of 371 posts

Re: WASM will replace containers

#301

Post by afiori »

jauntywundrkind wrote: post #168
danpalmer wrote: post #96

WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. Containers don't solve that pr…

You've shown that wasm solves a sandboxing/security concern that containers don't. But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success. I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be. The various wasm run…

Docker-like containers will likely exists as long as there linux servers, maybe the trendiness will leave them behind, but they are a plainly good technology to deploy and distribute application with many fantastic usecases.

I too do see a future where Wasm is way more widespread but as of now we are deploying a small app with a MySQL in single docker container. I suspect that we won't be running MySQL compiled to a Wasm container anytime soon*

* I suspect that we could with the right transpilations/interpreters but for sure we won't

Re: WASM will replace containers

#302

Post by euroderf »

bborud wrote: post #262

There is one thing that makes WASM very awkward: projecting APIs into a sandbox. If this was done in a way that works in mechanical sympathy with a wide range of languages I think WASM would be more successful. Making an API available inside a sandbox is painful. You have to manually roll something that can deal with memory, marshal calls and parameters etc. I'm not suggesting it is easy. I'm merely pointing out that…

Go development is ill-documented but just barely tolerable. Skip the BytecodeAlliance docs. Install WasmCloud's 'wash', write your WIT file, run 'wash build', and good luck with the error messages.

Re: WASM will replace containers

#303

Post by BrouteMinou »

mrkeen wrote: post #206
BrouteMinou wrote: post #70

Earlier quoted context omitted.

I think you meant Java Applets instead of Compile once run everywhere.

Right, now it's compile once, don't run on the web.

Well,for my part it's more: don't even compile, just run somewhere else.

Java is cool.

Re: WASM will replace containers

#305

Post by diego_moita »

mdaniel wrote: post #126
diego_moita wrote: post #22

Hmm, not sure... Author's argument is "because it is easier today and will be as powerful as containers in the future". Well, what about it gets as powerful but 3 times more complex? Frankly, I find it quite messy to develop WASM in C++ without downloading an emscripten ... container . Yeah, AFAIK, there is no WASM compiler in WASM. Oh an there is the *in the browser*, also. Yeah, but the truth of the matter is that…

> Yeah, AFAIK, there is no WASM compiler in WASM. What would you do with one if you had it? Run it on your wasm OS?

You noticed this post is about WASM replacing containers, right?

So, I'd use it the same way we use compilers in containers (i.e: one single download, no installation) and would run it with a runtime like Wasmer, Wasmtime, Wasmedge, etc.

Or else I could run it sandboxed in a browser as a PWA. Then you could build things in Chromebook, phone, etc.

Re: WASM will replace containers

#306

Post by mdaniel »

diego_moita wrote: post #305
mdaniel wrote: post #126

Earlier quoted context omitted.

> Yeah, AFAIK, there is no WASM compiler in WASM. What would you do with one if you had it? Run it on your wasm OS?

You noticed this post is about WASM replacing containers, right? So, I'd use it the same way we use compilers in containers (i.e: one single download, no installation) and would run it with a runtime like Wasmer, Wasmtime, Wasmedge, etc. Or else I could run it sandboxed in a browser as a PWA. Then you could build things in Chromebook, phone, etc.

> Or else I could run it sandboxed in a browser as a PWA.

  $ du -hs $HOMEBREW_CELLAR/gcc/*
  527M /usr/local/Cellar/gcc/14.2.0_1
(nod)

Re: WASM will replace containers

#307

Post by koiueo »

tombert wrote: post #142
koiueo wrote: post #139

Earlier quoted context omitted.

> "write once, run it on your specific server". Funny, how people forget that a "specific server" can be running Linux on bare metal ARM or a x86 container, or maybe Windows or even MacOS.

I guess what I'm trying to say is that you're not typically deploying JAR files outside of an extremely controlled environment. For a server environment, I set all the parameters I want and then I code around it. Obviously there's a lot of variation between different servers, but you typically develop your server code a specific set of servers.

And you don't have to think about your server architecture when you run unit tests on your jar locally from your M4 MacBook.

How convenient is that, huh?

Re: WASM will replace containers

#308

Post by kentonv »

bovermyer wrote: post #286

It's mentioned in passing in the article, but I'm intrigued by the author's mention of how Cloudflare Workers interoperate. Besides the official documentation, are there any articles anyone can recommend on this topic?

Cloudflare Workers run in V8 isolates, which are much lighter-weight than containers, with the ability to run thousands in the same process, and start up new ones quickly on-demand. For Cloudflare it's usually easier to start your application on the machine where it is requested, than to try to route to a machine where it's already running: https://developers.cloudflare.com/workers/reference/how-work...

The API construct that lets a worker call another worker (in the same process, in fact, in the same thread) is a Service Binding: https://blog.cloudflare.com/service-bindings-ga/

This is one type of "binding" or "live environment variable" or "capability". You configure it at deploy time, and then at runtime you can just do `env.SOME_SERVICE.fetch(request)` to call to your other worker: https://blog.cloudflare.com/workers-environment-live-object-...

There's a fancy RPC system, although it's (for now) centered on JavaScript so not as relevant to Wasm users: https://blog.cloudflare.com/javascript-native-rpc/

(I'm the tech lead for Cloudflare Workers.)

Re: WASM will replace containers

#309

Post by mardifoufs »

pjmlp wrote: post #289
RALaBarge wrote: post #285

Earlier quoted context omitted.

It isn't the fault of the group that suggests and standardizes protocols, it is everyone thinking they are smarter and they can do it better is the problem.

Especially when ignoring prior art, and why it eventually went away.

How is Wasm ignoring prior art? Like what mistakes have been made that were already known about before? Genuinely curious.
Post reply on HN