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

241–250 of 371 posts

Re: WASM will replace containers

#241

Post by syrusakbary »

The article is completely on point.

Personally, I don't think that Cloudflare is the best provider for Wasm at the Edge as everything needs to go through a Javascript layer that eventually hurts performance and prevents further optimization, but is a strong one nontheless (note: take everything with a grain of salt, even though I try hard to not be biased, I'm also founder of Wasmer)

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

Wasmer launched WASIX [1] a few years ago which fulfills the vision that the article describes. With WASIX you can have sandboxed access to:

  1. Filesystem
  2. Networking / Sockets
  3. Processes
  4. Threads
[1] https://wasix.org/

Re: WASM will replace containers

#242

Post by aqueueaqueue »

zfg wrote: post #198
taurknaut wrote: post #41

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.

Minified JS also makes that possible.

Re: WASM will replace containers

#243

Post by paul_h »

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

Java's SecurityManager was cool at the start, but over the years there was a steady series of ways to side step it. And now Oracle are wholly deleting it in JDK 25 - https://openjdk.org/jeps/486. It was a stand out feature IMO, and I'll miss it.

Re: WASM will replace containers

#244

Post by weinzierl »

Statically compiled portable binaries will replace containers.

Maybe not, but one can dream at least.

What do we need containers for, if we can build a service in a binary that you can throw on any Linux of the past 20 years and it just starts to serve network requests?

What do we need to support other platforms if the server world is one big Linux monoculture and the next best platforms are just a cross-compile away?

Why wouldn't I compile everything statically if containers don't share libraries anyway?

Re: WASM will replace containers

#245

Post by Joker_vD »

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…

WASM approach to injecting the host-interaction API seems to me to be similar to what EFI does. You are provided with a table full of magical functions on startup, and that's how you can interact with the host. Some functions weren't provided there? Tough luck.

Re: WASM will replace containers

#246

Post by fergie »

> You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM.

Is there any compelling reason not to just compile TypeScript to WASM? Why should it have JavaScript as its compile target?

Re: WASM will replace containers

#247

Post by MortyWaves »

fergie wrote: post #246

> You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM. Is there any compelling reason not to just compile TypeScript to WASM? Why should it have JavaScript as its compile target?

The closest to that is AssemblyScript which is terrible and painful to use with a broken developer tooling story.

Re: WASM will replace containers

#248

Post by weinzierl »

danpalmer wrote: post #96

WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. Containers don't solve that pr…

I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic.

I really hope WASM takes over as a plugin mechanism. I don't think it will lead to fragmentation because communities will form around their preferred language, it will just not be enforced anymore. And forcing a plugin language did not work so successfully to prevent fragmentation anyway, see GNU Guile or vimscript.

Re: WASM will replace containers

#250

Post by lmm »

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

Java write once run anywhere is fine. Java people don't generally bother with containers because there's no point, the JVM already solves the same problem.
Post reply on HN