91–100 of 313 posts
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...
"and non-JVM apps like PostgreSQL" PostgreSQL can (and has) been compiled to Wasm! It was on HN a couple of months ago https://news.ycombinator.com/item?id=33067962
Earlier quoted context omitted.
"We put all eggs in WASM basked, please adopt it!" - guy that founded a thing the rest of industry just did better before he was able to capitalize on it.
> the rest of industry just did better before Citation needed. Well, I know about BSD jails and Solaris (later Illumos, etc) zones. How easy were they to deploy to an average cloud? How easy was it to reproducibly build and distribute them? Or what else would you offer as a better docker alternative from 10 years ago?
>Citation needed.
Well if you actually read the whole sentence instead of bluescreening in middle of reading then deciding to comment on half of sentence that changes it meaning
> the rest of industry just did better before he was able to capitalize on it.
you'd maybe figure out that I was talking about k8s and such picking a container format and ditching the rest of things Docker made. Not stuff that came before.
Docker as a company got relegated to "a repository" that they decided to monetize so people started going around that too.
Earlier quoted context omitted.
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.
Surely it replaces/is an alternative to images, not containers? If I have a wasm binary, there's still value in specifying the environment in which it runs, volumes it has access to, networking, etc.?
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”
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.
You can run Postgres using WASM in two different ways[1][2]. That’s a non-trivial codebase.
1. https://www.crunchydata.com/blog/learn-postgres-at-the-playg...
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”
>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?
WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way.
WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, much higher level VM like the JVM.
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…
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
Of course they do. You can only run apps on WASM that have been compiled to WASM bytecode. You can only run apps on Docker that have been compiled to whatever bytecode is supported by the container runtime (which can be x86, ARM, x64, etc.).
> but WASM can run Postgres
WASM can run WASM-compiled Postgres. It has to be specifically compiled for WASM, which also means it generally needs to be ported to WASM first (as WASM runtimes have a lot of limitations that arbitrary C programs probably don't conform to).
Earlier quoted context omitted.
You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm . The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not…
> You can compile any C / C++ app down to wasm. This is incorrect, there is a long list of limitations that your C/C++ code must conform to in order to compile to WASM. There's a whole section dedicated to this in the Emscripten docs: https://emscripten.org/docs/porting/index.html . The chances your existing C/C++ app will compile to WASM and run correctly are much smaller than with Docker. However, the chances your…
LLVM bitcode isn't all that portable though, and of course, the binary will still be OS specific because C/C++ code relies on native APIs. The primary reason to do this is so the Graal JIT compiler can optimize native code and higher level dynamic script/bytecode together and remove interop overhead.
However, you can theoretically run whole programs this way inside the Graal sandbox. If you do that you get an emulation of POSIX that is reimplemented on top of the Java standard library, so the code becomes portable, and in managed mode there's an additional party trick - the native C/C++ malloc is replaced with garbage collected allocations and memory accesses are bounds checked. So code run this way gets all the memory safety errors blocked automatically. This upgrade comes with two costs though, one is slower execution/more memory usage, and the other is you have to buy GraalVM EE. The community edition can run bitcode, but not in the sandboxed/managed mode.
Oh and GraalVM can also run WASM. So you can have cake and eat it, everything running together via their 'polyglot' interop system.
Earlier quoted context omitted.
> the rest of industry just did better before Citation needed. Well, I know about BSD jails and Solaris (later Illumos, etc) zones. How easy were they to deploy to an average cloud? How easy was it to reproducibly build and distribute them? Or what else would you offer as a better docker alternative from 10 years ago?
"How easy were they to..." They weren't, like at all (yes, I have tried them). The dockerfile for repeatable (enough) image builds and the simple command line for running a container without having to mess with making a config for some init system is really the killer features of docker.