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

281–290 of 371 posts

Re: WASM will replace containers

#281

Post by sebstefan »

stackskipton wrote: post #83

As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure. > In the year 2030, no one will remember Kubernetes. So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/202…

WASM is powering Cloudflare workers in pretty much the fashion the guy describes and it does solve the problem of big latencies for cold starts with Lambda stuff

Instead of spinning up a container on-demand you spin up what is essentially a chrome tab in your V8 instance. Startup time is nil

In terms of solutions looking for a problem, that one seems to have fixed at least one problem for at least one person

It's pretty genius

Re: WASM will replace containers

#282

Post by afiori »

pjmlp wrote: post #193
hardwaresofton wrote: post #171

Earlier quoted context omitted.

> I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having…

DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL

The "universal compile target" facet of wasm is much less focal than the "universally embeddable" one.

The sandboxing is the keystone holding up the entire wasm ecosystem, without it no one would be interested in it same as nobody would run javacript in browsers without a sandbox (we used to, it was called flash, we no longer do).

I am curious why you focus so much on "universal runtime/compile-target do fail" rather than its actual strenght when at least in the case of java applet they failed because their sandbox sucked (and startup times).

Re: WASM will replace containers

#283

Post by pjmlp »

zfg wrote: post #265
pjmlp wrote: post #260

Earlier quoted context omitted.

And now we have all plugins back, that is the only utility for WebAssembly, doing two level translation of bytecodes.

WebAssembly is no more a plugin than JavaScript is.

Indeed, but it allows us to have our plugins back, and that is the only thing I care about.

https://cheerpj.com

https://opensilver.net/

https://vidkidz.github.io

Re: WASM will replace containers

#284

Post by evacchi »

orliesaurus wrote: post #11

lol I initially thought dylibso was the author, I was mistaken. That being said - WASM has been steadily improving over time, yet it hasn't quite achieved mainstream adoption. I'm curious what's holding it back? It seems like despite its technical advancements, WASM hasn't captured the public's interest in the same way some other technologies have. Perhaps it's a lack of easily accessible learning resources, or maybe…

> lol I initially thought dylibso was the author

as a Dylibso employee, I am wondering what made you think that :D at Dylibso we advocate for Wasm for software extensions, rather than an alternative to containers!

Re: WASM will replace containers

#285

Post by RALaBarge »

pjmlp wrote: post #194
hardwaresofton wrote: post #108

Earlier quoted context omitted.

Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces: https://github.com/WebAssembly/WASI/tree/main/wasip2 This is what people are building on, in the upstream, and in the bytecode alliance You're absolutely right about e…

CORBA, DCOM, RMI, .NET Remoting, Tcl Agents,... but this time it will be better.

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.

Re: WASM will replace containers

#286

Post by bovermyer »

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?

Re: WASM will replace containers

#287

Post by pjmlp »

milesrout wrote: post #264
pjmlp wrote: post #219

Earlier quoted context omitted.

As long as, people use their computers as PC towers from 2000, without hardware video decoding, sleep states, modern UEFI features. There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.

Hardware video decoding has worked perfectly for decades. Sleep worked perfectly until Microsoft decided that device manufacturers should replace sleep with overheating in your bag (a much better sleep mode than, y'know, actual SLEEP). Not sure what "modern UEFI features" means. Whenever something is described as "modern" that screams to me that someone is trying to conflate recentness with quality which is a red fla…

> Hardware video decoding has worked perfectly for decades.

That must be why Linux forums are full of VA-API tutorials and how to enable hardware decoding on Chrome then.

> UEFI itself has worked fine for as long as it has existed as far as I know?

Depends on the board, some boards don't play ball with Linux distros.

> Why you would replace the userland with "managed language frameworks" is quite beyond me.

Google has their reasons, as does LG, seems to work quite well in market share.

Re: WASM will replace containers

#288

Post by afiori »

pjmlp wrote: post #231
hardwaresofton wrote: post #226

Earlier quoted context omitted.

Except developers have consistently chosen not to embed the JVM, CLR, or IBMi. wasmtime (the current reference runtime implementation) is much more embeddable than these other options were/are, and is trivially embeddable in many languages today, with good performance. On top of being an option, it is being used , and WebAssembly is spreading cross-language, farther than the alternatives ever reached. These things ma…

As if developers are consistently chosing to embedd WASM, just wait after the hype cycle dies. What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM.

I believe that the two most likely futures for the wasm-as-puglin-engine are mod in games and applications with a generic extension interface.

IMO in games developers would prefer something with a reasonable repl like lua or javascript (as a game is already assumed to be heavy if the mods are not performance critical running a V8 should not be a problem) for extensions in generic complex applications (things like, VSCode, Blender, Excel, etc.) I would posit that the wasm sandbox could be a really good way to enable granular-permission secure extenstion.

Re: WASM will replace containers

#289

Post by pjmlp »

RALaBarge wrote: post #285
pjmlp wrote: post #194

Earlier quoted context omitted.

CORBA, DCOM, RMI, .NET Remoting, Tcl Agents,... but this time it will be better.

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.

Re: WASM will replace containers

#290

Post by titzer »

hardwaresofton wrote: post #116
quesomaster9000 wrote: post #105

Earlier quoted context omitted.

As somebody who's in the process of building a sandbox for RISC-V 64 Linux ELF executables, even I'm still on the fence. The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavo…

> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. At the application level, you're generally going to write to the standards + your embedding. Companies th…

> the downside is that it means you have to re-invent the world to work with this flavor of runtime.

This is at least one of the reasons we've been building thin kernel interfaces for Wasm. We've built two now, one for the Linux syscall interface (https://github.com/arjunr2/WALI) and one for Zephyr. A preliminary paper we wrote a year or so back is here (https://arxiv.org/abs/2312.03858), and we have a new one coming up in Eurosys 25.

One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. This makes it easier to then build things like WASI just one level up, compiled against the kernel interface and delivered as a Wasm module. Thus a single WASI implementation can be reused across engines.

Post reply on HN