16 ms·

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Sol

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225 https://twitter.com/solomonstre/status/1111004913222324225

pjmlp 4y ago
Indeed, he just had to make use of JVM or CLR based application servers instead. That is what this whole trend is all about, replicating application servers with WASM. Every time I need to dive into k8s stuff, I can only think "this was so much easier when configuring WebSphere and EAR deployments".
- orf 4y ago
  Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.
  - pjmlp 4y ago
    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.
    - ridruejo 4y ago
      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
      - pletnes 4y ago
        That’s what JVM promised! They just made Java so there would be at least one familiar-looking (to C++ devs) language for it. Indeed, there are quite a few JVM languages out there, just not as many as some had hoped in 1995.
      - cle 4y ago
        The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.
        acdha 4y ago
        Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.
        int_19h 4y ago
        The biggest problem when compiling to JVM bytecode isn't dynamic languages - even if they are slower, it's tolerable. It's stuff like C++, where the whole point is being fast, but JVM simply lacks the necessary primitives to compile to.
      - FlyingSnake 4y ago
        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?
      - pbecotte 4y ago
        It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task. There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"
    - orf 4y ago
      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”
      - pjmlp 4y ago
        Well, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
        orf 4y ago
        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
        pjmlp 4y ago
        Unfortunately it lacked the buzzwords of VC money to make it a trendy topic.
        sitkack 4y ago
        You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are aware of.
        layer8 4y ago
        Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.
    - imtringued 4y ago
      What's wrong with a "JVM but for everyone who isn't a Java developer"? If the model works, why shouldn't there be competitors and wide spread adoption?
      - pjmlp 4y ago
        Nothing, that is after all how CLR was designed, just lets not pretend it is something new.
      - espadrine 4y ago
        JVM wasn’t just for Java developers (Kotlin, Clojure, Ruby could compile to it); but it was easiest for Java, and other languages didn’t elect to build on the JVM interface by default, rather adopting POSIX (and either a custom bytecode or assembly) as the interface. WASM likely won’t convince all languages to switch to its bytecode by default. Its adoption story requires enough people to maintain this non-standard compilation pipeline. Which is fine, but beyond the bytecode, the productivity will only be maintained if it offers an equal or superior interface to POSIX. Right now, WASI is not it. A lot of basic elements are experimental, like file seek, multi-process, threads, SIMD, GPU programming… People will believe the hype, miss the caveats, use it at work, and have their project fail. Companies will blacklist the technology. In my mind, it is too early for them to be so publicly dithyrambic. All WASM publications should link to a page that details all WASI features that are still experimental.
      - fulafel 4y ago
        "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).
        dragonwriter 4y ago
        > "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc) .NET/Java/Clojure, maybe not. Ruby and Python work via an interpeter for the platform, just like they do on JVM/.Net, except that, unlike JVM/.NET, in both cases they can use the normal C-based interpreter, compiled for WASM.
  - cmrdporcupine 4y ago
    The problem is that WASM isn't really what you're saying. Yes, it's language agnostic. But as part of its agnosticism, it is also completely lacking in basically any runtime services. Yes, with WASI we get a POSIX-type API, but we're still lacking garbage collection, sophisticated memory management, optimized complex types, monitoring conventions etc. This is great for running existing "native" type code compiled from C/C++/Rust but its profoundly unsuited to the kind of development that most application or service developers do, which is in higher level languages with automatic memory management, monitoring / profiling services, etc. All of which either have to be re-invented in the WASM world, or run inside the WASM container at 2x or more the runtime/energy cost. And for what benefit? It's one thing to get a game engine running in a web browser. Neat hack / potentially decent way to ship a client. It's another thing to try to repackage existing working, relatively well engineered, server runtime systems inside it for almost no benefit at all. TDLR: WASM is not a universal VM appropriate for server apps. It is a solution for shipping a certain kind of application in a certain circumstance. There are other, better, solutions for "containerizing" services. Finally, after 25 years in this industry, the world I want to head to is higher level, where things are managed declaratively with explicit, visible, well described rules and relations and logic. WASM seems to me to push the other direction. Black boxes of fairly low-level code, each reinventing its own runtime wheel and with almost no visibility from the administration side of what's happening in there. I find that kind of sad.
    - orf 4y ago
      GC semantics are highly specific and coupled to the language. Of course WASM couldn’t (and shouldn’t!) deal with that. I mostly agree with your overall point though. I’m not making the point that WASM right now (or even later) is the future of deploying backend services, however it is somewhat of a universal VM. If it’s a useful one is yet to be seen.
      - cmrdporcupine 4y ago
        Yes, of course they're highly specific. And that's my point. Why would I run a GC language inside my WASM runtime, at a 2-3x or more performance overhead? Instead of just running that languages' existing runtime which has been tuned for years, and already provides its own virtual machine? What is the actual benefit? Putting it more clearly: Most services development is done in languages that have their own virtual machine (JS/TS, Go, JVM, Python, .NET). In what world does it make sense to run that VM inside another VM? Finally, I think the experiences over the last 20 years around .NET and the JVM should have shown there is in fact not really such a thing as a truly universal abstract VM. A well-written VM tends to be written towards supporting the language(s) it is built for. ... Not unless you're willing to throw away almost all added value, and then you start looking like WASM. And then what's your value beyond native code, running on the hypervisor and/or in a container? (There are in fact proposals for adding GC hooks in WASM. I'd have to spend some time reading up on them to evaluate whether they address my objections.)
- threeseed 4y ago
  a) Kubernetes is far simpler and more consistent to me than WebSphere/EAR. b) Kubernetes is the platform as well as the application server.
  - pjmlp 4y ago
    The amount of YAML spaghetti I have to deal with says otherwise.
    - bzzzt 4y ago
      Dealing with the XML spaghetti from most Java EE containers isn't much better though.
      - pjmlp 4y ago
        - Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.
        orf 4y ago
        Literally every single one of those are well supported by Kubernetes and YAML. 1 and 3 are actually foundational to how k8s works. Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.
        pjmlp 4y ago
        So fundamental that those tools don't exist at all.
        orf 4y ago
        Hey, so I thought I remembered your username. This isn’t the first interaction we’ve had, or I’ve seen you have, that follows this similar pattern. In fact it’s the third example from you under this post! It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage. Please understand that if you post your hot takes here they may be discussed and challenged, and if you don’t want this then I would refrain from initially commenting. In response to your comment: They do. All Kubernetes resources are typed with JSON-schema definitions. Because of course they are, how else would kubernetes validate anything. https://kubernetesjsonschema.dev/ https://kubernetesjsonschema.dev/ Anyone who’s used k8s at all knows this, if only from the error messages. From this you get autocompletion and a wide ecosystem of gui configuration tools that work with everything, including custom resource definitions, which is really cool. I used to like lens (https://k8slens.dev/desktop.html https://k8slens.dev/desktop.html), but now I use the k8s plugins from IntelliJ
- ilyt 4y ago
  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.
  - pjmlp 4y ago
    Even being language-agnostic was a path already trailed by Burroughs and IBM mainframes, besides lots of other ones.
    - ilyt 4y ago
      Well, everything in IT is circular, just before you had to pay tens of millions to IBM for the priviledge
Cloudef 4y ago
Expect now you need to compile / port everything to WASM+WASI...
- angelmm 4y ago
  Hey! A WasmLabs team member here :). We're planning to port several runtimes as part of our WebAssembly Language Server initiative [1]. Porting things to Wasm+WASI is sometimes challenging. There are some deep-dives in our blog around this topic [2]. [1] https://github.com/vmware-labs/webassembly-language-runtimes/ https://github.com/vmware-labs/webassembly-language-runtimes... [2] https://wasmlabs.dev/articles/php-wasm32-wasi-port/ https://wasmlabs.dev/articles/php-wasm32-wasi-port/
  - zcw100 4y ago
    I'll start by saying I'm a big fan of wasm but just a couple of comments about the articles. I really with the WebAssembly community would stop quoting that tweet from Solomon Hykes. It's taken somewhat out of context and while at the time it was a big shoutout to the wasm underdog it's now a bit over used. Wasm really needs to justify itself with more than just a tweet and I think that it can. "Polyglot - 40+ languages can be compiled to Wasm" is a bit misleading which anyone would see if you listed the 40+ languages. A lot of them are going to be very obscure ones and a lot of the popular ones are on that list. Factually correct but you're just setting people up to be disappointed. "40+ languages oh boy!.....What the heck is Zig? and no Python?!" (yes, I know you can sort of run Python if you run the entire interpreter)
- ridruejo 4y ago
  Right now is tricky and looks like a Rube-Goldberg machine to get many things running. However, it is getting easier and easier to do so. Eventually you will not have to do the compilation itself, but there will be plenty of Wasm binaries ready to use. This will be similar to Linux, most people don't compile the source code for apps from scratch, just use the distro package manager
- ClumsyPilot 4y ago
  Which si way easier than supporting 15,000 distros of linux
pulse7 4y ago
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...
- nkozyra 4y ago
  Maybe I'm misunderstanding, but my thought was he was suggesting that the host/VM could be written in WASM, which could then run any arbitrary thing as Docker does today.
- krona 4y ago
  JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?
  - zozbot234 4y ago
    Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way. In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.
    - imtringued 4y ago
      That doesn't work. Java web apps have failed. Nobody uses Java in the browser anymore. So even if we use JVM bytecode as the intermediary language you would need to translate that into ASM.js and then you basically introduced arbitrary complexity for literally no reason and you won't have the performance benefit of webassembly. The browser engine developers effectively paid a huge up front fixed cost and now anyone can use Webassembly in nodejs which then spills over to more and more use cases like cryptocurrencies using a modified WASM VM for their zk sync layer two solution. The JVM simply wasn't built for these use cases.
      - gpderetta 4y ago
zozbot234 4y ago
Docker containers will still be far more efficient than something which has to be interpreted in a VM. The real advantage of WASM/WASI is architecture independence - and perhaps some kind of trusted verification of proof assertions in the code, which would of course be easier in a VM compared to trying to verify actual binary assembly.
- MrJohz 4y ago
  Wasm doesn't need to be interpreted, it's designed to be compatible with streaming compilers to produce machine code as the file is being downloaded, which can then be optimised more completely later on. In a Docker-like situation, I would imagine that you can skip the first compilation step altogether and just generate optimised code. I suspect that still won't be as optimal as if you'd compiled the application for the target architecture in the first place, but I would suspect for most applications the performance will be relatively negligible.
- _joel 4y ago
  I'm still unsure how this is of benefit vs. multi-arch images? Sure one build to rule them all but using buildx isn't exactly too much work.
maxloh 4y ago
There are some other aspects that docker cannot be replaced. For example, making sure build works accross different platforms and machines. There are too many ways that something may break, incorrect SDK versions, missing dependencies etc. Docker makes sure the OS (container) to be setup correctly to handle the build.
- sp332 4y ago
  Something like the docker build tools would still be needed, but not the docker runtime.
  - maxloh 4y ago
    Maybe Nix[0] is what you want. It is founded for providing a way to produce reproducible builds. [0]: https://nixos.org/ https://nixos.org/
- chriswarbo 4y ago
  > For example, making sure build works accross different platforms and machines Unfortunately Docker only works on Linux, since it's tied to specific syscalls. Those on other platforms (e.g. macOS) can only run it in a VM (e.g. the Docker Desktop application is built on top of a VM running Linux) > here are too many ways that something may break, incorrect SDK versions, missing dependencies etc. AFAIK Docker doesn't actually address that. It provides a "Dockerfile", which is essentially just a shell script; users still have to manage dependencies themselves, e.g. by having their Dockerfile invoke an actual package manager. > Docker makes sure the OS (container) to be setup correctly to handle the build. Containers aren't operating systems; they only need the desired executable, plus its run-time dependencies (e.g. libc).
  - my123 4y ago
    > Unfortunately Docker only works on Linux And Windows. On Windows, Docker can actually create and manage Windows containers in addition to Linux ones. macOS just doesn't have the namespacing primitives for such a scenario as far as I'm aware.
ilyt 4y ago
"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.
- nine_k 4y ago
  > 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?
  - chillfox 4y 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.
    - ilyt 4y ago
      Oh the crimes against engineering that were required to run chroots and such, I don't miss those. Even LXC/LXD was a bit janky with it desperately trying to be "light sorta VM"
  - ilyt 4y ago
    >> the rest of industry just did better before >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.
nine_k 4y ago
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 environment, with zero performance penalty. It's very unlike WASM / WASI approach which requires recompiling stuff, runs non-native code, and completely changes the environment in which the code has to run. It's also like 2x as slow, compared to native code. It has its important upsides, but they are very unlike Docker's, in my eyes.
- ClumsyPilot 4y ago
  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.
  - cmeacham98 4y ago
    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.
    - Thaxll 4y ago
      Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.
      - cmeacham98 4y ago
        I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier. Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.
mhh__ 4y ago
Does it actually exist now?
runlaszlorun 4y ago
I’m not anti-WASM but this quote is way overrused. It’s like the Godwin’s law of WASM…

pjmlp 4y ago

Indeed, he just had to make use of JVM or CLR based application servers instead. That is what this whole trend is all about, replicating application servers with WASM. Every time I need to dive into k8s stuff, I can only think "this was so much easier when configuring WebSphere and EAR deployments".

orf 4y ago
Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.
- pjmlp 4y ago
  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.
  - ridruejo 4y ago
    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
    - pletnes 4y ago
      That’s what JVM promised! They just made Java so there would be at least one familiar-looking (to C++ devs) language for it. Indeed, there are quite a few JVM languages out there, just not as many as some had hoped in 1995.
    - cle 4y ago
      The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.
      - acdha 4y ago
        Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.
        int_19h 4y ago
        The biggest problem when compiling to JVM bytecode isn't dynamic languages - even if they are slower, it's tolerable. It's stuff like C++, where the whole point is being fast, but JVM simply lacks the necessary primitives to compile to.
    - FlyingSnake 4y ago
      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?
    - pbecotte 4y ago
      It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task. There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"
  - orf 4y ago
    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”
    - pjmlp 4y ago
      Well, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
      - orf 4y ago
        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
        pjmlp 4y ago
        Unfortunately it lacked the buzzwords of VC money to make it a trendy topic.
      - sitkack 4y ago
        You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are aware of.
        layer8 4y ago
        Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.
  - imtringued 4y ago
    What's wrong with a "JVM but for everyone who isn't a Java developer"? If the model works, why shouldn't there be competitors and wide spread adoption?
    - pjmlp 4y ago
      Nothing, that is after all how CLR was designed, just lets not pretend it is something new.
    - espadrine 4y ago
      JVM wasn’t just for Java developers (Kotlin, Clojure, Ruby could compile to it); but it was easiest for Java, and other languages didn’t elect to build on the JVM interface by default, rather adopting POSIX (and either a custom bytecode or assembly) as the interface. WASM likely won’t convince all languages to switch to its bytecode by default. Its adoption story requires enough people to maintain this non-standard compilation pipeline. Which is fine, but beyond the bytecode, the productivity will only be maintained if it offers an equal or superior interface to POSIX. Right now, WASI is not it. A lot of basic elements are experimental, like file seek, multi-process, threads, SIMD, GPU programming… People will believe the hype, miss the caveats, use it at work, and have their project fail. Companies will blacklist the technology. In my mind, it is too early for them to be so publicly dithyrambic. All WASM publications should link to a page that details all WASI features that are still experimental.
    - fulafel 4y ago
      "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).
      - dragonwriter 4y ago
        > "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc) .NET/Java/Clojure, maybe not. Ruby and Python work via an interpeter for the platform, just like they do on JVM/.Net, except that, unlike JVM/.NET, in both cases they can use the normal C-based interpreter, compiled for WASM.
- cmrdporcupine 4y ago
  The problem is that WASM isn't really what you're saying. Yes, it's language agnostic. But as part of its agnosticism, it is also completely lacking in basically any runtime services. Yes, with WASI we get a POSIX-type API, but we're still lacking garbage collection, sophisticated memory management, optimized complex types, monitoring conventions etc. This is great for running existing "native" type code compiled from C/C++/Rust but its profoundly unsuited to the kind of development that most application or service developers do, which is in higher level languages with automatic memory management, monitoring / profiling services, etc. All of which either have to be re-invented in the WASM world, or run inside the WASM container at 2x or more the runtime/energy cost. And for what benefit? It's one thing to get a game engine running in a web browser. Neat hack / potentially decent way to ship a client. It's another thing to try to repackage existing working, relatively well engineered, server runtime systems inside it for almost no benefit at all. TDLR: WASM is not a universal VM appropriate for server apps. It is a solution for shipping a certain kind of application in a certain circumstance. There are other, better, solutions for "containerizing" services. Finally, after 25 years in this industry, the world I want to head to is higher level, where things are managed declaratively with explicit, visible, well described rules and relations and logic. WASM seems to me to push the other direction. Black boxes of fairly low-level code, each reinventing its own runtime wheel and with almost no visibility from the administration side of what's happening in there. I find that kind of sad.
  - orf 4y ago
    GC semantics are highly specific and coupled to the language. Of course WASM couldn’t (and shouldn’t!) deal with that. I mostly agree with your overall point though. I’m not making the point that WASM right now (or even later) is the future of deploying backend services, however it is somewhat of a universal VM. If it’s a useful one is yet to be seen.
    - cmrdporcupine 4y ago
      Yes, of course they're highly specific. And that's my point. Why would I run a GC language inside my WASM runtime, at a 2-3x or more performance overhead? Instead of just running that languages' existing runtime which has been tuned for years, and already provides its own virtual machine? What is the actual benefit? Putting it more clearly: Most services development is done in languages that have their own virtual machine (JS/TS, Go, JVM, Python, .NET). In what world does it make sense to run that VM inside another VM? Finally, I think the experiences over the last 20 years around .NET and the JVM should have shown there is in fact not really such a thing as a truly universal abstract VM. A well-written VM tends to be written towards supporting the language(s) it is built for. ... Not unless you're willing to throw away almost all added value, and then you start looking like WASM. And then what's your value beyond native code, running on the hypervisor and/or in a container? (There are in fact proposals for adding GC hooks in WASM. I'd have to spend some time reading up on them to evaluate whether they address my objections.)
threeseed 4y ago
a) Kubernetes is far simpler and more consistent to me than WebSphere/EAR. b) Kubernetes is the platform as well as the application server.
- pjmlp 4y ago
  The amount of YAML spaghetti I have to deal with says otherwise.
  - bzzzt 4y ago
    Dealing with the XML spaghetti from most Java EE containers isn't much better though.
    - pjmlp 4y ago
      - Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.
      - orf 4y ago
        Literally every single one of those are well supported by Kubernetes and YAML. 1 and 3 are actually foundational to how k8s works. Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.
        pjmlp 4y ago
        So fundamental that those tools don't exist at all.
        orf 4y ago
        Hey, so I thought I remembered your username. This isn’t the first interaction we’ve had, or I’ve seen you have, that follows this similar pattern. In fact it’s the third example from you under this post! It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage. Please understand that if you post your hot takes here they may be discussed and challenged, and if you don’t want this then I would refrain from initially commenting. In response to your comment: They do. All Kubernetes resources are typed with JSON-schema definitions. Because of course they are, how else would kubernetes validate anything. https://kubernetesjsonschema.dev/ https://kubernetesjsonschema.dev/ Anyone who’s used k8s at all knows this, if only from the error messages. From this you get autocompletion and a wide ecosystem of gui configuration tools that work with everything, including custom resource definitions, which is really cool. I used to like lens (https://k8slens.dev/desktop.html https://k8slens.dev/desktop.html), but now I use the k8s plugins from IntelliJ
ilyt 4y ago
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.
- pjmlp 4y ago
  Even being language-agnostic was a path already trailed by Burroughs and IBM mainframes, besides lots of other ones.
  - ilyt 4y ago
    Well, everything in IT is circular, just before you had to pay tens of millions to IBM for the priviledge

Cloudef 4y ago

Expect now you need to compile / port everything to WASM+WASI...

angelmm 4y ago
Hey! A WasmLabs team member here :). We're planning to port several runtimes as part of our WebAssembly Language Server initiative [1]. Porting things to Wasm+WASI is sometimes challenging. There are some deep-dives in our blog around this topic [2]. [1] https://github.com/vmware-labs/webassembly-language-runtimes/ https://github.com/vmware-labs/webassembly-language-runtimes... [2] https://wasmlabs.dev/articles/php-wasm32-wasi-port/ https://wasmlabs.dev/articles/php-wasm32-wasi-port/
- zcw100 4y ago
  I'll start by saying I'm a big fan of wasm but just a couple of comments about the articles. I really with the WebAssembly community would stop quoting that tweet from Solomon Hykes. It's taken somewhat out of context and while at the time it was a big shoutout to the wasm underdog it's now a bit over used. Wasm really needs to justify itself with more than just a tweet and I think that it can. "Polyglot - 40+ languages can be compiled to Wasm" is a bit misleading which anyone would see if you listed the 40+ languages. A lot of them are going to be very obscure ones and a lot of the popular ones are on that list. Factually correct but you're just setting people up to be disappointed. "40+ languages oh boy!.....What the heck is Zig? and no Python?!" (yes, I know you can sort of run Python if you run the entire interpreter)
ridruejo 4y ago
Right now is tricky and looks like a Rube-Goldberg machine to get many things running. However, it is getting easier and easier to do so. Eventually you will not have to do the compilation itself, but there will be plenty of Wasm binaries ready to use. This will be similar to Linux, most people don't compile the source code for apps from scratch, just use the distro package manager
ClumsyPilot 4y ago
Which si way easier than supporting 15,000 distros of linux

pulse7 4y ago

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

nkozyra 4y ago
Maybe I'm misunderstanding, but my thought was he was suggesting that the host/VM could be written in WASM, which could then run any arbitrary thing as Docker does today.
krona 4y ago
JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?
- zozbot234 4y ago
  Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way. In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.
  - imtringued 4y ago
    That doesn't work. Java web apps have failed. Nobody uses Java in the browser anymore. So even if we use JVM bytecode as the intermediary language you would need to translate that into ASM.js and then you basically introduced arbitrary complexity for literally no reason and you won't have the performance benefit of webassembly. The browser engine developers effectively paid a huge up front fixed cost and now anyone can use Webassembly in nodejs which then spills over to more and more use cases like cryptocurrencies using a modified WASM VM for their zk sync layer two solution. The JVM simply wasn't built for these use cases.
    - gpderetta 4y ago

zozbot234 4y ago

Docker containers will still be far more efficient than something which has to be interpreted in a VM. The real advantage of WASM/WASI is architecture independence - and perhaps some kind of trusted verification of proof assertions in the code, which would of course be easier in a VM compared to trying to verify actual binary assembly.

MrJohz 4y ago
Wasm doesn't need to be interpreted, it's designed to be compatible with streaming compilers to produce machine code as the file is being downloaded, which can then be optimised more completely later on. In a Docker-like situation, I would imagine that you can skip the first compilation step altogether and just generate optimised code. I suspect that still won't be as optimal as if you'd compiled the application for the target architecture in the first place, but I would suspect for most applications the performance will be relatively negligible.
_joel 4y ago
I'm still unsure how this is of benefit vs. multi-arch images? Sure one build to rule them all but using buildx isn't exactly too much work.

maxloh 4y ago

There are some other aspects that docker cannot be replaced. For example, making sure build works accross different platforms and machines. There are too many ways that something may break, incorrect SDK versions, missing dependencies etc. Docker makes sure the OS (container) to be setup correctly to handle the build.

sp332 4y ago
Something like the docker build tools would still be needed, but not the docker runtime.
- maxloh 4y ago
  Maybe Nix[0] is what you want. It is founded for providing a way to produce reproducible builds. [0]: https://nixos.org/ https://nixos.org/
chriswarbo 4y ago
> For example, making sure build works accross different platforms and machines Unfortunately Docker only works on Linux, since it's tied to specific syscalls. Those on other platforms (e.g. macOS) can only run it in a VM (e.g. the Docker Desktop application is built on top of a VM running Linux) > here are too many ways that something may break, incorrect SDK versions, missing dependencies etc. AFAIK Docker doesn't actually address that. It provides a "Dockerfile", which is essentially just a shell script; users still have to manage dependencies themselves, e.g. by having their Dockerfile invoke an actual package manager. > Docker makes sure the OS (container) to be setup correctly to handle the build. Containers aren't operating systems; they only need the desired executable, plus its run-time dependencies (e.g. libc).
- my123 4y ago
  > Unfortunately Docker only works on Linux And Windows. On Windows, Docker can actually create and manage Windows containers in addition to Linux ones. macOS just doesn't have the namespacing primitives for such a scenario as far as I'm aware.

ilyt 4y ago

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

nine_k 4y ago
> 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?
- chillfox 4y 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.
  - ilyt 4y ago
    Oh the crimes against engineering that were required to run chroots and such, I don't miss those. Even LXC/LXD was a bit janky with it desperately trying to be "light sorta VM"
- ilyt 4y ago
  >> the rest of industry just did better before >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.

nine_k 4y ago

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 environment, with zero performance penalty. It's very unlike WASM / WASI approach which requires recompiling stuff, runs non-native code, and completely changes the environment in which the code has to run. It's also like 2x as slow, compared to native code. It has its important upsides, but they are very unlike Docker's, in my eyes.

ClumsyPilot 4y ago
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.
- cmeacham98 4y ago
  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.
  - Thaxll 4y ago
    Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.
    - cmeacham98 4y ago
      I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier. Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.

mhh__ 4y ago

Does it actually exist now?

runlaszlorun 4y ago

I’m not anti-WASM but this quote is way overrused. It’s like the Godwin’s law of WASM…