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

111–120 of 371 posts

Re: WASM will replace containers

#111

Post by mdaniel »

lylejantzi3rd wrote: post #49
tombert wrote: 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.

The Orca project is attempting to do exactly that: https://github.com/orca-app/orca

> Windows 10 or later, or Mac 13 or later (Linux is not yet supported)

Aww, man, they nixed my chances of trying that out on _both_ of my local machines in one fell swoop (still on macOS 12.7 because it works fine)

Does this thing, really, seriously, need the most bleeding edge Darwin toys?! Come to think of it, I bet $1 it's because GHA only goes down to 13 https://docs.github.com/en/actions/using-github-hosted-runne...> It seems GL is in the same boat https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.h...>

Re: WASM will replace containers

#112

Post by stlava »

> In the year 2030, no one will remember Kubernetes.

I highly doubt that. Maybe there will be an evolution to k8s but fundamentally it solves a whole host of challenges around defining the environment an application runs in.

Re: WASM will replace containers

#113

Post by ridiculous_fish »

chambers wrote: post #50

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

At $WORK we use SQLite in WASM via the official ES module, running read-only in browser.

The performance is very poor, perhaps 100x worse than native. It's bad enough that we only use SQLite for trivial queries. All joins, sorting, etc. are done in JavaScript.

Profiling shows the slowdown is in the JS WASM interop. This is exacerbated by the one-row-at-a-time "cursor" API in SQLite, which means at least one FFI round-trip for each row.

Re: WASM will replace containers

#115

Post by mdaniel »

tombert wrote: post #84
mdaniel wrote: post #14

Earlier quoted context omitted.

We could name it the Abstract Window Toolkit and it would render the same on every platform. But then, someone would get butthurt about it having a "distinct look" and decide to make the Standard Widget Toolkit that uses native bindings. Fantastic that it stops that distinct look, with the small asterisk that you now have to ship .dll/.so/.dylib shims in your "cross platform" app I'm no wasm expert, but I find it jus…

> I'm no wasm expert, but I find it just fantastically unlikely that they're going to beat the decades of research that have gone into the JIT in the JVM anytime soon Probably not, but that's sort of orthogonal to my point. Java started as "write once run anywhere", but it has almost become the opposite of that: "write once, run it on your specific server". "Portability" is not nearly the same concern with Java as it…

You say that, and yet for your cited Android apps, they are built using gradle, which is written for the JVM, or using Maven, which is written for the JVM, and likely even typed inside IntelliJ (aka Android Studio) which is written for the JVM. Also, this may be splitting hairs, but Android is actually dalvik, not the JVM

Re: WASM will replace containers

#116

Post by hardwaresofton »

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…

> 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 that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction.

For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP:

https://github.com/WebAssembly/wasi-http

It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against.

As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc:

https://github.com/webassembly/wasi-libc

Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months).

The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.

Re: WASM will replace containers

#117

Post by azakai »

hardwaregeek wrote: post #24

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…

Lots of people use wasm in production right now, and toolchain support is in a good place across several languages. In that sense we are already there.

You likely visited a website using wasm today without realizing it, and major apps like Photoshop have been ported to wasm, which was the original dream behind it all. That has all succeeded.

But if you want to replace containers specifically, as this article wants, then you need more than wasm 1.0 or even 2.0. I don't know when that future will arrive.

Re: WASM will replace containers

#118

Post by chambers »

ridiculous_fish wrote: post #113
chambers wrote: post #50

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

At $WORK we use SQLite in WASM via the official ES module, running read-only in browser. The performance is very poor, perhaps 100x worse than native. It's bad enough that we only use SQLite for trivial queries. All joins, sorting, etc. are done in JavaScript. Profiling shows the slowdown is in the JS WASM interop. This is exacerbated by the one-row-at-a-time "cursor" API in SQLite, which means at least one FFI round…

Yup, I've tested and seen WASM SQlite's slowness myself. But I don't think it's a SQLite problem per se.

I heard WebSQL, which used SQLite, was at least 10x faster than WASM SQLite. Probably even more.

Re: WASM will replace containers

#119

Post by invalidname »

moribvndvs wrote: post #93

One benefit of being an old engineer is watching how excited people get when they rediscover something that has gone around the bend over and over again. I swear if you fuckers reinvent DCOM I will shit in your hats.

Exactly. It's like the JVM circa 2004. Without all the observability and features we have today and half the performance/reliability/security.

Re: WASM will replace containers

#120

Post by mdaniel »

openquery wrote: post #59
neom wrote: post #37

Earlier quoted context omitted.

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

Or even the other direction, upward toward full vms, or hybrid: https://github.com/kubevirt/kubevirt/blob/v1.4.0/docs/archit...
Post reply on HN