Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

81–90 of 313 posts

Re: WebAssembly: Docker Without Containers

#81
post #5

Earlier quoted context omitted.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

Scala, Kotlin, Groovy proved that JVM can be used as a compilation target. Same was proven with Iron* languages on CLR. How is it different this time?

Re: WebAssembly: Docker Without Containers

#82
post #73
post #66

Earlier quoted context omitted.

Well, having essentially a VM that was supposedly designed to be language-agnostic and easy to sandbox is a benefit over a VM that is designed for single language and never put much thought into embedding.

Even being language-agnostic was a path already trailed by Burroughs and IBM mainframes, besides lots of other ones.

Well, everything in IT is circular, just before you had to pay tens of millions to IBM for the priviledge

Re: WebAssembly: Docker Without Containers

#83
post #13
post #9

Earlier quoted context omitted.

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?

[deleted]

Re: WebAssembly: Docker Without Containers

#84
post #8
post #5

Earlier quoted context omitted.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

While it’s true that it somewhat locks you into a single VM type (WASM), that’s very different from being locked into the JVM. For one, the idea is that it should be fairly simple to compile an arbitrary program to WASM, allowing you to use a far wider variety of languages. In this case, it’s more akin to “docker with extra steps” as opposed to “docker but you can only hire Java devs”

>single VM type (WASM), that’s very different from being locked into the JVM.

Why is that different?

Re: WebAssembly: Docker Without Containers

#85
post #64

Earlier quoted context omitted.

Yes! Wasm builds on top of 20 years of experience and improvements of JVM, CLR. There are a few key differences, but one important one is the universal adoption by the industry (no ActiveX vs Applets war, .NET vs Java) with companies as varied as Google, Apple, Amazon, Microsoft actively cooperating on moving the standard forward. I have never seen anything like that and I hope it continues for as long as possible!

> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pas…

Not sure what the point is here, but that reality for .NET never really came to fruition. Now only C# and a tiny sliver of F# really dominate most of development on .NET.

Re: WebAssembly: Docker Without Containers

#86
post #67
post #8

Earlier quoted context omitted.

While it’s true that it somewhat locks you into a single VM type (WASM), that’s very different from being locked into the JVM. For one, the idea is that it should be fairly simple to compile an arbitrary program to WASM, allowing you to use a far wider variety of languages. In this case, it’s more akin to “docker with extra steps” as opposed to “docker but you can only hire Java devs”

Well, http://nestedvm.ibex.org/

If the best counterpoint I could find is a dead proof of concept project from over a decade ago that only works on an unsupported compiler released 17 years ago, I would reevaluate my position

Re: WebAssembly: Docker Without Containers

#87
post #65

Earlier quoted context omitted.

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker).

This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Re: WebAssembly: Docker Without Containers

#88
post #8
post #5

Earlier quoted context omitted.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

While it’s true that it somewhat locks you into a single VM type (WASM), that’s very different from being locked into the JVM. For one, the idea is that it should be fairly simple to compile an arbitrary program to WASM, allowing you to use a far wider variety of languages. In this case, it’s more akin to “docker with extra steps” as opposed to “docker but you can only hire Java devs”

Can you actually compile an arbitrary program to WASM? I thought they had to be ported to WASI first and can't use any operating system APIs. Otherwise, how can it be sandboxed? Arbitrary programs can call into arbitrary OS-native APIs and execute arbitrary native code outside the bounds of the WASM VM, including things like JITing native code.

Re: WebAssembly: Docker Without Containers

#89
post #9

Earlier quoted context omitted.

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

> JVM+JAR existed JVM can only run apps written for it: Docker & WASM don't have that limitation. > it can run non-WASM and non-JVM apps like PostgreSQL, etc... but WASM can run Postgres

With GraalVM you can run WASM on JVM...

Re: WebAssembly: Docker Without Containers

#90
post #65

Earlier quoted context omitted.

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

Didn't say secure though, just isolated. Often I'm fine with some subset of isolation.
Post reply on HN