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

321–330 of 371 posts

Re: WASM will replace containers

#321

Post by afiori »

aqueueaqueue wrote: post #238
pjmlp wrote: post #223

Earlier quoted context omitted.

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.

Ah COBOL, Fortran, Perl and PHP.... all chant: "No no.... we're actually modern now guys!!!"

Being modern has little to do with being used, at least COBOL and PHP have for sure strong footholds in many places

Re: WASM will replace containers

#322

Post by Stevvo »

npodbielski wrote: post #315
Stevvo wrote: post #141

Earlier quoted context omitted.

WASM can run on real hardware. e.g. innative.dev

Seems kinda dead. Last release 2 years ago and last commit nine months.

It's used in Flight Simulator, but Microsoft have their own fork with changes not contributed upstream.

Re: WASM will replace containers

#323

Post by Evidlo »

akdas wrote: post #189
Evidlo wrote: post #187

Does anyone remember a presentation on YouTube that described a hypothetical future where everything will be running inside a VM in a browser?

The Birth and Death of Javascript. One of my favorites! https://www.destroyallsoftware.com/talks/the-birth-and-death...

Thanks, that was it!

Re: WASM will replace containers

#324

Post by int_19h »

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…

As things are, all browser developers - including Firefox! - disable hardware acceleration on most video cards in their browsers on Linux because it is "too unstable". The result is a 20% difference in battery life between Linux and Windows if you mostly do browsing.

Re: WASM will replace containers

#325

Post by TZubiri »

danpalmer wrote: post #130
TZubiri wrote: post #125

Earlier quoted context omitted.

Wasm: client, user's device Containers: server, dev's device Cmon OP try to keep up

Well, not quite, that's an oversimplification. As I mentioned I think there's a place for WASM as the common unit of business logic, for things like plugins. Implementing a FaaS runtime like Lambda is actually quite hard to do in a way that is both safe and multi-language. Compiling down to a safe, sandboxed bytecode, is not a bad idea, regardless of whether you're doing that to run it in a user's browser, or to run…

Yeah sure, there was a time people believed that about javascript, and node.js ended up being a tool used to build website middle-ends and BFF to connect to actual backends.

The user's device which can be a smartphone or a latpop and the developer's device which can be a 24 hour online server or a 24 hour online server, are just two completely different devices that cannot be abstracted away.

WASM is a technology that was born for the frontend, and js was a technology that was born for the frontend, you can for sure metastasize the web front towards the back, but then you end up with a web bias in the frontend (why not make the backend in swift, or Java for phones?, or whatever language will be used for new tech like LLM voice assistants?) and of course a frontend bias in the backend.

Not a good look, let's stop it with the full stack thing, let's specialize, half of use do backend, half of you do frontend, and then we keep on specializing, if everyone does everything we'll cover no ground.

Re: WASM will replace containers

#326

Post by taurknaut »

aqueueaqueue wrote: post #240
taurknaut wrote: post #41

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

Damn. I didn't get the memo on containers being useless. Better tell my boss my last 3 months work is actually going to take a year. On a serious note. What's missing in containers? Maybe they could be a bit more Nixxy? (Just use Nix to make the container)

> What's missing in containers?

From a consumer/user perspective almost none of the benefit of containers is available to the end-user. Features sets vary wildly by operating system. MacOS doesn't even have real containerization and apple has not signaled moving in that direction. (not even going to bother to take windows seriously.) jails in FreeBSD work in a completely different way from cgroups. Our phones should effectively be containerizing apps so we can e.g. control who is allowed to contact the internet, but no such functionality is offered to the user. Apps instead are simply not allowed to look at each other, but they can contact whoever they want. (Maybe a rooted android has slightly better feature set in this regard, but that sounds miserable to me to have to figure out.)

For writing services, yes, they're quite useful. We've only tapped a tiny part of the potential though. These could be easily repurposed to allow the end-user who uses graphical interfaces to lock down their computer.

Re: WASM will replace containers

#327

Post by SSLy »

v3ss0n wrote: post #263
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…

When did docker started using LXD ? i never knew.

never, they GP is wrong

Re: WASM will replace containers

#328

Post by Humphrey »

mkl wrote: post #235
Humphrey wrote: post #18

Disagree: While this might be the case for a handful of languages such as Rust of Go - Many lanugages need a whole lot of other stuff to run (eg, Python needs a lot bunch of dependencies).

I thought the same at first, but found Python Cloudflare Workers already run in WASM: https://developers.cloudflare.com/workers/languages/python/h...

Ah interesting! Looks like that uses a WASM build of CPython to run your Python code - similar to how you can run python in your browser. Would you still have a heap of Python files?

Re: WASM will replace containers

#329

Post by yencabulator »

titzer wrote: post #290
hardwaresofton wrote: post #116

Earlier quoted context omitted.

> 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 co…

> One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines.

Such a low burden that both Google (gVisor) and Microsoft (WLS1) failed at it!

Re: WASM will replace containers

#330

Post by josephg »

danpalmer wrote: post #129
josephg wrote: post #104

Earlier quoted context omitted.

True. Its probably worth creating a validation suite for wasi which can check that any given implementation implements all the functions correctly & consistently. Like, I'm imagining a wasm bundle which calls all the APIs it expects in every different configuration and outputs a scorecard showing what works properly and what doesn't. I suspect you're right - unless people are careful, it'll be a jungle out there. Jus…

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. That also assumes that everyone involved wants compatibility, and that's unlikely. Imagine a world where e…

> 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.

Yeah - but its barely a problem today compared to a few decades go. I do a lot of work on the web, and its pretty rare these days to find my websites breaking when I test them on a different web browser. That used to be the norm.

I think essentially any time you have multiple implementations of the same API you want a validation test suite. Otherwise, implementation inconsistencies will creep in. Its not a wasm thing. Its just a normal compatibility thing.

Commonmark is a good example of what doing this right looks like. The spec is accompanied by a test suite - which in their case is a giant JSON list containing input markdown text and the expected output HTML. Its really easy to check if any given implementation is commonmark compliant by just rendering everything in the list to HTML and checking that the output matches:

https://spec.commonmark.org/

> Most companies implementing WASM will tend to want to a) control the spec in their own favour, and b) gain advantages over other implementations. And this is why we can't have nice things.

Your cynicism seems miscalibrated. We have hundreds of examples of exactly this kind of successful cross-company collaboration in computing. For example, at the IETF you'll find working groups for specs like TCP, HTTP, BGP, Email, TLS and so on. The HTTP working group alone has hundreds of members, from hundreds of companies. WhatWG and the W3C do the same for browser APIs. Then there's hardware groups - who manage specs like USB, PCI / PCIe, Bluetooth, Wifi and so on. Or programming language standards groups.

Compatibility can always be better, but generally its great. We can have nice things. We do have nice things. WASM itself is an example of that. I don't see any reason to see these sort of collaborations stopping any time soon.

Post reply on HN