Live data from Hacker News

WASM will replace containers

creston.blog

51–60 of 371 posts

Re: WASM will replace containers

#51
post #6
post #4

[flagged]

> PlatformOps (formerly DevOps (formerly Ops)) team Formerly sys admin

> Formerly sys admin

Formerly systems programmer, or sysprog for short

"Config files? What are those? To change the system configuration, use these assembler macros, reassemble this module, relink the operating system and then reIPL it". So, systems programmer, because knowing assembler was part of the job description.

Plus, at mainframe sites in the 1960s/1970s, it was common for sysprogs to write custom code to hook into the operating system and change its behaviour (user exits), or even to actually patch the operating system code (SYSMOD) – and assembler was the language used to do all that

If we are talking about IBM mainframes specifically, by the 1970s, a lot of the operating system was written in a high level language (a PL/I dialect), but although they shipped customers the source code, they didn't ship them any compiler for the special PL/I dialect, so customers couldn't modify it by changing the source, only by disassembling the binary, modifying the assembly, then reassembling it. Plus, commonly, IBM shipped only source for the initial release, not later patches, so the customer copy of the source would gradually get out of sync with the binary. Some other mainframe vendors weren't quite so primitive, and so there was significantly less use of assembler by customers for OS customisation (e.g. I think, Burroughs, Multics)

Re: WASM will replace containers

#52
I'm always reminded of Gary Bernhardt's "the birth and death of javascript" when wasm gets discussed. While it's a bit tongue-in-cheek, I think it really drives home that it's really just another layer of abstraction that may or may not be useful for a given problem, and might not be the silver bullet that anyone is looking for. I recon that whether or not wasm will take over everything will mostly be about trade offs between it and the other solutions.

Re: WASM will replace containers

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

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

So basically virtual machines, those we can spin up with lxd or firecracker. Not that they don't have file access, it's just that's finnicky compared to containers (I'm thinking docker/podman)

Re: WASM will replace containers

#54

I found WASM slower than expected. I wrote some WASM logic functions recently which I thought would perform better than their native JS equivalent. For example, take a large array and "pivot" it in 10ms instead of a 100ms. What I found was the JS version was a bit faster than the compiled WAT. Yikes. EDIT: I think I'll try debugging it more

the answer will be; depends what ur doing. There is a cost communicating with a worker

Re: WASM will replace containers

#55
post #47

When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…

Blazor is stable and extremely easy to use. It’s just a little slow to load, although there are ways to mitigate that.

Blazor is a great developer experience but when you put it side by side with the other technology solutions (react, angular, anything really) its so slow that you will quickly be told to use something else...

Re: WASM will replace containers

#56

Earlier quoted context omitted.

Well, AWS, typically.

Are you sure? Are those instances a VM or another docker container? Does anyone from amazon know?

It's a custom VM they wrote called Nitro: https://aws.amazon.com/ec2/nitro/

Re: WASM will replace containers

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

>But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc.

So an operating system?

Re: WASM will replace containers

#58

I found WASM slower than expected. I wrote some WASM logic functions recently which I thought would perform better than their native JS equivalent. For example, take a large array and "pivot" it in 10ms instead of a 100ms. What I found was the JS version was a bit faster than the compiled WAT. Yikes. EDIT: I think I'll try debugging it more

the answer will be; depends what ur doing. There is a cost communicating with a worker

[deleted]

Re: WASM will replace containers

#59
post #37

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.

...you're essentially turning the host OS into both a resource manager and isolation boundary enforcer, which is... kind of what hypervisors were specifically designed to do, just at a different level. When the container companies were all starting to come out, I never thought it was a good idea, given what I was building I never said anything because "of course the VM guy would not like containers" - I thought many…

I haven't played around with hypervisors much but the whole point of k8s is not just isolation but all the primitives the control plane gives you which you don't need to implement. Things like StatefulSet, ReplicaSet, Volumes, HorizontalPodAutoscaler, Service, DNS, ConfigMaps, Secrets, Accounts, Roles, Permissions etc.

Also the container runtime which is containerd by default I believe can be switched out for micro vms like Firecracker (never done this though - not sure how painful it is).

Post reply on HN