Live data from Hacker News

WASM will replace containers

creston.blog

221–230 of 371 posts

Re: WASM will replace containers

#221

Earlier quoted context omitted.

WASM will be that but tenfold surely? You would need to program against a completely new interface.

Wasm is getting merged in and designed in a way that it is "drop in". As in, the standard libs are written to do WASI calls instead of libc (or whatever else) for standard I/O concerns. This is represented in some languages better than others -- for many languages you just switch the "target" -- from x86_64-unknown-linux-gnu to wasm32-wasip2 (ex. Rust). Some things won't work, but most/many will (simple file access,…

Basically CORBA with RMI and .NET Remoting.

Re: WASM will replace containers

#222

Earlier quoted context omitted.

> I understand your point but sadly I think it's too idealistic (not that we shouldn't strive for these goals). We already have those sorts of tests for browsers, and browser compatibility is still a problem. We have acceptance tests for other areas, like Android's CTS tests, but there are still incompatibilities. > I think the browser problem is a marketshare/market power problem, and Wasm doesn't have that problem.…

> I think the browser problem is a marketshare/market power problem, and Wasm doesn't have that problem. No, it really isn’t. For more than the last two decades every browser bar IE looked towards compatibility and only included differences as browser-specific extensions. And even when Microsoft eventually caved and started the Edge project to create a compatible browser, they ended up admitting defeat and pivoted to…

Maybe I'm just not understanding, but I'm not sure how this precludes it being a marketshare problem -- the thing is that the marketshare leader doesn't have to worry about compatibility/being interoperable.

> And even when Microsoft eventually caved and started the Edge project to create a compatible browser, they ended up admitting defeat and pivoted to Chromium themselves.

This can be interpreted as a problem of marketshare not staying balanced. It may have shifted hands, but the imbalance is the problem -- if Chrome had to deal with making changes that would be incompatible with half the users that visit sites on Chrome, they'd be forced to think a lot more about it.

This doesn't mean they can't add value in the form of non-standardized extensions -- that's not a desirable goal because it would stifle innovation. The point is that at some point if users are on browser Y and they get a "this site only runs on browser X", they're just not going to visit that site, and developers are going to shy away from using that feature. In a world with lopsided marketshare, there's not much incentive for the company with the most marketshare to be interoperable.

Re: WASM will replace containers

#223
post #163

> In the year 2030, no one will remember Kubernetes. As a sys admin, no, we will have to remember. Once a system is in place and "functions", they tend to stay for a long time.

I believe at least one consulting company in this Indian city is still training new graduates in COBOL and setting them up with dead end careers.

COBOL just had a new release, COBOL 2023 is the most recent standard.

Also does objects nowadays.

Additionally, given all the AI prompts being used nowadays writing long English texts instead of proper programming, COBOL was actually a language ahead of its time.

Re: WASM will replace containers

#224
post #2

It would be so great if WASM gives us the paradise that Java promised thirty years ago. Being able to get fast, "write once, run anywhere" would be awesome. I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.

> I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves. https://github.com/slint-ui/slint

Still not half as feature rich as Swing, or JavaFX, since we are talking about bytecode ecosystems.

Re: WASM will replace containers

#225
post #29

Earlier quoted context omitted.

Containers will never replace VMs either. People will be running WASM inside of containers inside of VMs.

Where did this extra VM come from?

See https://katacontainers.io

Turns out only containers is not secure enough.

Re: WASM will replace containers

#226
post #200

Earlier quoted context omitted.

Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model. Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm. The closer comparison is probably the JVM -- but with support for many…

https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/IBM_i#TIMI Really this is only new for those that weren't around, many other examples, even older available.

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 may look the same, but just like ssh/scp and dropbox, they're not the same once you zoom/dig in to what's different this time.

Re: WASM will replace containers

#227
post #33

Naw. The purpose of docker is like a VM. To simulate the running of two or more server machines with OS's to run on one machine. wasm is like java.

or wasm is just faster client-side javascript

More like return of Applets, Flash, Silverlight, ActiveX.

And that is great, thanks to it is all turtles to the way down, I can have my plugins back, now running on WebAssembly, that is the only thing I care about it.

Re: WASM will replace containers

#229
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,…

> That's what killed the Java write-once, run-anywhere promise.

I write Java software on Intel and deploy to an arm device.

The promise seems to work for me.

Re: WASM will replace containers

#230
post #198

No. Wasm is not useful enough yet. Neither are containers.

How else am I supposed to use a Visual Basic 6 clone written in C# in my browser? https://bandysc.github.io/AvaloniaVisualBasic6/ https://github.com/BAndysc/AvaloniaVisualBasic6 WebAssembly brings all languages to the browser and that's a good thing. I can write applications for the desktop in any language, I should be able to do the same thing in the browser. WebAssembly makes that possible.

Back in the day you would have used .NET plugin for browsers, which got replaced by Silverlight plugin, nowadays it is WebAssembly, really nothing new per se.
Post reply on HN