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

201–210 of 371 posts

Re: WASM will replace containers

#201

Post by pjmlp »

Capricorn2481 wrote: post #73
resonious wrote: post #23

Earlier quoted context omitted.

This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

Basically yet another bytecode based runtime, but being sold as if it is the very first of its kind, despite prior history.

Re: WASM will replace containers

#202

Post by pjmlp »

hardwaresofton wrote: post #175
Capricorn2481 wrote: post #73

Earlier quoted context omitted.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

> I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Yes, this is a key value of WebAssembly compared to other approaches, it is a relatively (compared to a container or a full blown VM) lightweight way to package and…

IronPython alongside C++/CLI on the CLR, everything compiled down to MSIL bytecodes.

Re: WASM will replace containers

#203

Post by pjmlp »

tyingq wrote: post #91
Capricorn2481 wrote: post #73

Earlier quoted context omitted.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

The closest way to visualize it is probably how cloudflare offers something kind of like a container (if you squint) via it's workers product. https://blog.cloudflare.com/announcing-wasi-on-workers/ I assume the merit for cloudflare is lower overhead cost per worker than if they had done something more like AWS lambda. Explained better than I can, here: https://developers.cloudflare.com/workers/reference/how-work...…

Even closer WebLogic, WebSphere, JBoss, Glassfish in 2002, but now instead of a EAR file, it is a WASM one.

Re: WASM will replace containers

#204

Post by funcDropShadow »

josephg wrote: post #95
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…

> True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.

All of this sounds too good to be true. The JVM tried to use one abstraction to abstract different processor ISAs, different operating systems, and a security boundary. The security boundary failed completely. As far as I understand WASM is choosing a different approach here, good. The abstraction over operating systems was a partial failure. It succeeded good enough for many types of server applications, but it was never good enough for desktop applications and system software. The abstraction over CPU was and is a big success, I'd say.

What exactly makes you think it is easier with WASM as a CPU abstraction to do all the rest again? Even when thinking about so diverse use-cases like in-browser apps and long running servers.

A big downside of all these super powerful abstraction layer is reaction to upstream changes. What happens when Linux introduces a next generation network API that has no counterpart in Windows or in the browser. What happens if the next language runtime wants to implement low-latency GC? Azul first designed a custom CPU and later changed the Linux API for memory management to make that possible for their JVM.

All in all the track record of attempts to build the one true solution for all our problems is quite bad. Some of these attempt discovered niches in which they are a very good fit, like the JVM and others are a curiosity of history.

Re: WASM will replace containers

#206

Post by mrkeen »

BrouteMinou wrote: post #70
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

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

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

Re: WASM will replace containers

#207

Post by fwsgonzo »

quesomaster9000 wrote: post #105
josephg wrote: post #95

Earlier quoted context omitted.

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…

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…

As someone who has written a RISC-V sandbox for that purpose, I say stay the course. We need more competition to WASM. At the end you'll find that register machines make for faster interpreters than Harvard architectures. You can have a look at libriscv or message me if you need any help.

Source: https://libriscv.no/docs/performance/

Re: WASM will replace containers

#209

Post by nindalf »

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 sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.

Could you expand on this? I think everyone would agree with the first two of these - sandboxing is the whole point of WASM, so it would be excellent at that. And startup latency matters a great deal to WASM programs, again not surprised that runtimes have optimised that.

But execution speed compared to native? Are you saying WASM programs execute faster than native? Or even at the same speed?

Re: WASM will replace containers

#210

Post by hansmayer »

The second paragraph is perhaps something you experience on a very small team in a very small company, but definitely not everyone's day-to-day experience and it sounds like the author would like to impose their own limited experience onto the whole industry. In a lot of companies the DevOps usually jump in and handle the entire management of the pipeline, including the build and release of containers. For most of developers, they still get to simply ship their features, I've rarely met classic developers 'optimising Docker build times'. Secondly, great technologies have intrinsic qualities and potential which get recognised instantly. Now there may be some hype following them, for sure, but it is these intrinsic qualities which silently drive the adoption of the new tech, not the hype. People starting building extensions and add-ons and more complex systems and suddenly you see it everywhere. WASM has been around for a few years now / anyone seen it make its way quietly into our working processes yet?
Post reply on HN