27 ms·

WebAssembly: Docker Without Containers

468 points by RebootStr 4y ago

tony-allan 4y ago
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…
deleted 4y ago
[deleted]
jdowner 4y ago
So, 'write once, run everywhere'... I think we've been here before.
- ridruejo 4y ago
  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!
  - pjmlp 4y ago
    > > 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, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. -- February 2002 issue of MSDN Magazine https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://learn.microsoft.com/en-us/archive/msdn-magazine/2002...
    - CharlieDigital 4y ago
      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.
      - javcasas 4y ago
        Well, Microsoft has always been about "our stuff is first class citizen, everything else is second class citizen". You could see that in the 2000s when Microsoft claimed Windows 2003 to be multiplatform because it could run binaries from windows 95, windows 98, windows 2000 and windows xp. What happened with .net is that C# is first class, F# is second class, and everything else is third class citizen at best (when not directly attacked via patent litigation).
haspok 4y ago
So it's kind of like GraalVM with cgroups? How about Kubernetes, in other words, how does this scale (I understand the single process proposition, but can't see how it replaces multiple containers, which might be deployed on multiple VMs / hardware)? In other words, what is the WASM runtime running on? In the article they show a WASI layer, but that does not replace a VM / container (AFAIK), so you still need an OS to run on. I'm a bit puzzled. EDIT: let me rephrase my question. In a docker container you can have your libraries and dependencies independent of the host system (eg. in your container you need libc 1.0, whereas your host system has libc 2.0). This is possible because the docker container does actually contain a copy of libc 1.0 if you set it up so. But in the case of WebAssembly this is no longer the case (this is what makes it possible to have smaller images). But then you need not only the kernel from the host, but everything else around it. Unless your code does not depend or anything, or you compile ALL your dependencies to webassembly, which sounds interesting - I'm not saying it is not possible, but is this how it should work?
- _joel 4y ago
  Yea, unsure how this replaces compose or how it would work in pods. Is there some kind of runtime planned to replace container.io so that you still get all the k8s orchestration (live/readiness, anti affininity, cgroups limits etc).
  - cpuguy83 4y ago
    The way this works is it uses a containerd shim. In containerd-land, shims are responsible for all the platform dependent setup/management of a container. The "normal" shim on Linux is the runc shim (io.containerd.runc.v2). On Windows the shim is called runhcs (io.containerd.runhcs.v1). The docker solution mentioned in the article modifies the "wasmtime" shim from https://github.com/containerd/runwasi https://github.com/containerd/runwasi so that it uses "wasmedge" instead. It also happens to be using an unreleased version of dockerd. So how does this work with compose? Currently you need to specify the runtime for the container, there should be an option in the compose yaml for this. How does it work with pods? You need to configure containerd's cri config with a runtime handler that specifies the wasmedge shim. Then you add a RuntimeClass to k8s and add that to your pod spec.
azangru 4y ago
When will we reach a point when articles and talks no longer start with "let me explain to you what webassembly is". After all, you don't see the same introductions in articles about javascript, or python, or even rust. When seeing an article starting with such introduction - after hundreds of other articles did the same - I never know how deep to expect it to go, and whether to continue reading.
- ridruejo 4y ago
  I completely understand and we debated it a lot when writing the article. At the end, given that the audience was existing Docker users, we erred on the side of adding that introduction. In other, more technical articles we just dive right in: https://wasmlabs.dev/articles/php-dev-server-on-wasm/ https://wasmlabs.dev/articles/php-dev-server-on-wasm/
  - kenjackson 4y ago
    I thought the intro was good and important. I’d read about web assembly before, but I learned new stuff in the intro.
- bityard 4y ago
  I thought it was pretty useful and I got quite a bit out of it. Most articles of this type gloss over why Wasm is even interesting, leaving me to wonder if Wasm is equivalent to Java Web Applets, or go jump right into implementation details of some subset of the project without any context. I often see a lot of technical articles posted to HN that are probably very interesting, but they assume the reader is living in the author's head and jump right into the details with little to no context.
pharmakom 4y ago
Docker is useful because I can throw any old POSIX library into a container and it will work in the cloud. How does WASM help here?
- ridruejo 4y ago
  It is a bit more involved (getting easier by the day) but you can do the same AND run it anywhere from a browser to an IoT device to ... a container :)
  - jmholla 4y ago
    Do you have a link to a guide or any sources on the on-going work? I'm with many of the commenters here agreeing that WebAssembly does not sufficiently replace Docker containers and would love to see what's happening on this front.
_0w8t 4y ago
Despite the sandboxing one still cannot run untrsuted WASM code in the same process as trusted code due to hardware bugs. CPU vendors are not going to fix those anytime soon. Their message is to always use separated address space for security isolation. And since one need an external process in any case, native containers wins as they are faster by factor of two over WASM. EDIT: It does not even make sense to use WASM inside a native container as an extra security layer. With the overhead of WASM one can just put a container inside a VM and still run things faster.
- goodpoint 4y ago
- bastawhiz 4y ago
  > native containers wins If your threat model includes hardware bugs, then a container doesn't really help, no? You can't really trust your containers without sandboxing them, and then you're killing your performance anyway.
  - _0w8t 4y ago
    Heavily sandboxed container has overhead of few percents. A hardware VM slows things down by 10-20% for a typical application. So even combining VM with a container will still be significantly faster than WASM.
    - bastawhiz 4y ago
      For the runtime, yes. But the cost of sending information into and out of a VM/container versus staying in the same process is costly, especially for small amounts of computation. And you're also comparing decades of VM and container investment to a handful of years of investment in WASM. WASM code today will run faster by a huge margin in a few years as the compilers improve. But moreover, most folks don't care about hardware bugs letting untrusted code break out of a sandbox. Bugs have been letting code break out of VMs, even, for years. If a hardware bug is discovered, you install the microcode update or kernel patch and move on. Which is to say, the performance isn't the reason for choosing WASM. It's good enough, in many cases. Being able to write a hundred or two lines of code to get pretty-fast and pretty-damn-secure sandboxing without needing to waste your time setting up and maintaining an elaborate breakfast machine of VMs and containers is the draw.
oxff 4y ago
Docker doesn't even .. really fix the issue it claims / is-used-for. I think nix does that, but it's pure pain to use. But it does actually address IME the repro issues.
OJFord 4y ago
> [...] take a look at WebAssembly as the 'successor' to containers and the next logical step in infrastructure deployment [and so on about containers] 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.?
- paulgb 4y ago
  It seems this is replacing both, in that the wasm module is not run inside of a traditional linux container (at least as far as cgroups go). > Each traditional container gets its own control group as in docker/ee44.... On the other hand, Wasm containers are included as part of the podruntime/docker control group and one can indirectly observe their CPU or Memory consumption.
jeroenhd 4y ago
What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associated with that, but leveraging virtual machines instead solves that issue. There are already proof of concept implementations to replace Docker with VMs as a virtualisation layer, so I wonder if it wouldn't be better to invest time in getting those wrappers completely up and running rather than coming up with essentially "Java but we also emulate the OS". Until WASM advocates start including benchmarks in their blogs, I'll keep watching this stuff from a distance.
- et1337 4y ago
  The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.
  - moss2 4y ago
    > This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.
    - hermanradtke 4y ago
      This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
      - koonsolo 4y ago
        On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
solomatov 4y ago
Does anyone has any links to recent benchmarks which show how large is the gap between WASM and native code? In theory WASM looks really great, but the last time I looked at it, the gap was big enough to be a concern.
- kllrnohj 4y ago
  The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting. Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the price of portability after all.
  - solomatov 4y ago
    But how large is this gap? I.e. 10%, 50%, 100% or 1000%. Size of this gap affects trade offs of using WASM vs native code a lot.
    - TUSF 4y ago
      It varies by the runtime, and the codegen of the WASM itself. From some benchmarks & anecdotes I've seen, the faster runtimes (v8, Spidermonkey, WAVM) are within about 10-50% of native speeds, give or take. There's also some runtimes (like Wasmer & WAVM) which provide the option to AOT compile your WASM module to native. In those cases, the gap from native is much smaller. But so far the JIT for WASM is just immature. That said, from what I've read, it looks like starting up a new WASM instance is pretty fast, so some places are using it for when they need to spawn up tons of instances all at once, without having to wait for a whole process to warm up.
Havoc 4y ago
Is there a way to do this from CLI already? Or still desktop only feature?
deleted 4y ago
[deleted]
nashashmi 4y ago
I once imagined a time in a far, faraway land where the new OS secretly in development was nothing more than a thin interface between the hardware and the software. And the software was a VM. And this was codenamed Fuchsia. And was being worked on by Google. They took away the lessons learned from CHromeOS with its LXC containers and Android Container. And realized the new OSs of the future can be anything and everything for anyone and everyone. And opening 35 applications meant running 35 different VMs made of 17 unique OSs and this was called a software's full-stack. And then I would check the memory usage only to be horrified my 128 GB RAM was nearly full, and RAM was just not enough. Then I snapped out of this nightmare. Are we intentionally not thinking about RAM usage in this dystopian world where we celebrate WASM-Docker progress without thinking of the drawbacks: memory inefficiencies?
- angelmm 4y ago
  Actually, Wasm goes into the direction you are pointing. A Wasm runtime should add a little overhead to the requirements of the Wasm module. However, it's true Wasm is not on that point yet. There are open threads about deallocate Wasm memory [1]. However, I expect these features, as well as Garbage Collection [2] will come to the stardard over time. This will allow modules and runtimes to properly manage memory usage. [1] https://stackoverflow.com/a/51544868 https://stackoverflow.com/a/51544868 [2] https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc
  - cma 4y ago
    If I run two programs with the same shared libraries, the nonrelocated parts are not duplicated in memory (and if I fork, the relocated parts aren't either). Does wasm map shared memory from disk like this, for the translated executable code?
- klabb3 4y ago
  Fuchsia natively does not use VMs for isolation (although there might be some compat effort that tries to do that). In fact, fuchsia is shipped to one of the lowest-end devices on the market - an old gen smart display. It also uses content addressable FS to deduplicate shared deps. Remember, nightmares aren’t real.
nikeee 4y ago
One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to. If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff from V8 for that. Any idea why they did not include these kinds of permissions in the WASI standard? It seems like WASI was not designed to be run without some sandbox.
- pie_flavor 4y ago
  No, you are not getting this right, and these permissions are built into the WASI standard.
- angelmm 4y ago
  That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking. For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With this, you can give access to a folder to a module and that module may call another one without giving them those permissions. In other ecosystems, any library used by the "main" logic gets the same permissions.
  - cma 4y ago
    Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?
    - agent281 4y ago
      You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.
jensenbox 4y ago
I stopped reading once I saw the article was targeting PHP. I am sure this is a great technology but really hard to see the benefit over standard docker. Does anyone have a pro/con list for docker and wasm at the server? Is there a "Use Docker when..." or a "Use WASM when..." style guidance?
enriquto 4y ago
If you are going to recompile everything statically into a new target, why don't just build an αpε? It seems like a more elegant and clean solution.
spullara 4y ago
AWS Lambda SnapStart makes all these alternative, constrained serverless systems look pretty painful for little gain. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
alzaeem 4y ago
How is it possible that the image size is so much smaller with the WASM image compared to the Docker image? They need to ship the entire php runtime compiled to WASM, so I don’t see how it can be smaller
- the_gipsy 4y ago
  What do you think is in the docker image?
  - alzaeem 4y ago
    They showed the WASM image is 5mb vs 30mb for the alpine Docker image. So that’s 25mb of overhead due to the alpine distro?
    - the_gipsy 4y ago
      That could be the main factor.
jbverschoor 4y ago
So what's the purpose of Docker according to Docker? Reproducible builds, consistent dev environments? I always thought it was to have production and development environments the same, but these statements contradict that.. Unless they expect you to run WASM on your servers..
- vlunkr 4y ago
  > Unless they expect you to run WASM on your servers They do, this is an emerging idea. > I always thought it was to have production and development environments the same This seems to be the first thing many people try to do with Docker. IMO it's actually not a great experience. In dev, you need to make changes, in prod, you shouldn't, so they're not the same at all. Docker has many strengths: reproducible builds, consistent deployment strategies(k8s doesn't care what's in your container), a consistent DSL for building apps, The ability to extend a huge collection of other Dockerfiles to get what you want. I'm sure there are more.
tinyspacewizard 4y ago
This totally missed the point. I use Docker where the compilation story (and cross-compilation story) is a mess (looking at you, Python) and I don't have the resources to figure it all out. With Docker, I can get a portable image working in a few hours. It's a hack, but it's a convenient one. WASM does not offer this.
- b33j0r 4y ago
  It’s people who see the potential of this emergent technology getting prematurely excited. It promises to neutralize the playing field like Java promised, and Docker. I’ve seen WASM do some cool shit, don’t count it out. Just factor in the irrational exuberance.
  - quickthrower2 4y ago
    I am bullish on WASM because technical merits aside it is in the browser and so it will be widely used because everyone knows it will be widely used. JS now runs on or is a source everywhere for example: embedded, frontend, backend, edge, mobile. WASM will be the same. In addition with so many compile to JS technologies and chains, WASM is sort of another choice. Not a big deal for a team to choose it. I don’t know enough about will it replace docker. But a lot of docker use cases are a bit of a leaky abstraction over what you are trying to achieve. For example why do I need to know what Alpine Linux is in order to run a node app? OK there is a node image that hides this detail but barely, you end up having to think about this sort of stuff.
    - b33j0r 4y ago
      It’s pretty cool to write a 3D game in godot, and see a browser run it like it’s nothin. It answers the question “but can it run linux/doom?” easily. Does it have the marketshare to make AWS make significantly different decisions? Remains to be seen. I guess people paid money for serverless. Could go that way Edit: I never thought node.js would take over half of the information sphere, so read me more like a graybeard who is too young to be one.
    - 4y ago
moyix 4y ago
Is there some page or document that explains how this actually works from the point of view of a traditional container / UNIX process worldview? Like, have the WASM folks implemented an emulation layer for Linux system calls? For libc? POSIX? Or maybe you need to modify your traditional programs so that they use WASM APIs instead? Just very confused at the moment :) I get the core idea of compiling other languages to WASM, but at the end of the day they have to talk to the outside world somehow right?
- peterhunt 4y ago
  I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
  - moyix 4y ago
    Aha! Thanks. :) So it sounds like it's a new capability-based syscall interface, but they've ported big chunks of libc (specifically musl) to that interface so that a lot of things work.
    - peterhunt 4y ago
      Yes, that's my understanding, but I've never actually used it :)
btbuildem 4y ago
"Docker without containers" -- proceed to build a docker container with wasm runtime inside. I don't think I get this.

468 points by RebootStr 4y ago

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…

deleted 4y ago

[deleted]

jdowner 4y ago

So, 'write once, run everywhere'... I think we've been here before.

ridruejo 4y ago
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!
- pjmlp 4y ago
  > > 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, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. -- February 2002 issue of MSDN Magazine https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://learn.microsoft.com/en-us/archive/msdn-magazine/2002...
  - CharlieDigital 4y ago
    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.
    - javcasas 4y ago
      Well, Microsoft has always been about "our stuff is first class citizen, everything else is second class citizen". You could see that in the 2000s when Microsoft claimed Windows 2003 to be multiplatform because it could run binaries from windows 95, windows 98, windows 2000 and windows xp. What happened with .net is that C# is first class, F# is second class, and everything else is third class citizen at best (when not directly attacked via patent litigation).

haspok 4y ago

So it's kind of like GraalVM with cgroups? How about Kubernetes, in other words, how does this scale (I understand the single process proposition, but can't see how it replaces multiple containers, which might be deployed on multiple VMs / hardware)? In other words, what is the WASM runtime running on? In the article they show a WASI layer, but that does not replace a VM / container (AFAIK), so you still need an OS to run on. I'm a bit puzzled. EDIT: let me rephrase my question. In a docker container you can have your libraries and dependencies independent of the host system (eg. in your container you need libc 1.0, whereas your host system has libc 2.0). This is possible because the docker container does actually contain a copy of libc 1.0 if you set it up so. But in the case of WebAssembly this is no longer the case (this is what makes it possible to have smaller images). But then you need not only the kernel from the host, but everything else around it. Unless your code does not depend or anything, or you compile ALL your dependencies to webassembly, which sounds interesting - I'm not saying it is not possible, but is this how it should work?

_joel 4y ago
Yea, unsure how this replaces compose or how it would work in pods. Is there some kind of runtime planned to replace container.io so that you still get all the k8s orchestration (live/readiness, anti affininity, cgroups limits etc).
- cpuguy83 4y ago
  The way this works is it uses a containerd shim. In containerd-land, shims are responsible for all the platform dependent setup/management of a container. The "normal" shim on Linux is the runc shim (io.containerd.runc.v2). On Windows the shim is called runhcs (io.containerd.runhcs.v1). The docker solution mentioned in the article modifies the "wasmtime" shim from https://github.com/containerd/runwasi https://github.com/containerd/runwasi so that it uses "wasmedge" instead. It also happens to be using an unreleased version of dockerd. So how does this work with compose? Currently you need to specify the runtime for the container, there should be an option in the compose yaml for this. How does it work with pods? You need to configure containerd's cri config with a runtime handler that specifies the wasmedge shim. Then you add a RuntimeClass to k8s and add that to your pod spec.

azangru 4y ago

When will we reach a point when articles and talks no longer start with "let me explain to you what webassembly is". After all, you don't see the same introductions in articles about javascript, or python, or even rust. When seeing an article starting with such introduction - after hundreds of other articles did the same - I never know how deep to expect it to go, and whether to continue reading.

ridruejo 4y ago
I completely understand and we debated it a lot when writing the article. At the end, given that the audience was existing Docker users, we erred on the side of adding that introduction. In other, more technical articles we just dive right in: https://wasmlabs.dev/articles/php-dev-server-on-wasm/ https://wasmlabs.dev/articles/php-dev-server-on-wasm/
- kenjackson 4y ago
  I thought the intro was good and important. I’d read about web assembly before, but I learned new stuff in the intro.
bityard 4y ago
I thought it was pretty useful and I got quite a bit out of it. Most articles of this type gloss over why Wasm is even interesting, leaving me to wonder if Wasm is equivalent to Java Web Applets, or go jump right into implementation details of some subset of the project without any context. I often see a lot of technical articles posted to HN that are probably very interesting, but they assume the reader is living in the author's head and jump right into the details with little to no context.

pharmakom 4y ago

Docker is useful because I can throw any old POSIX library into a container and it will work in the cloud. How does WASM help here?

ridruejo 4y ago
It is a bit more involved (getting easier by the day) but you can do the same AND run it anywhere from a browser to an IoT device to ... a container :)
- jmholla 4y ago
  Do you have a link to a guide or any sources on the on-going work? I'm with many of the commenters here agreeing that WebAssembly does not sufficiently replace Docker containers and would love to see what's happening on this front.

_0w8t 4y ago

Despite the sandboxing one still cannot run untrsuted WASM code in the same process as trusted code due to hardware bugs. CPU vendors are not going to fix those anytime soon. Their message is to always use separated address space for security isolation. And since one need an external process in any case, native containers wins as they are faster by factor of two over WASM. EDIT: It does not even make sense to use WASM inside a native container as an extra security layer. With the overhead of WASM one can just put a container inside a VM and still run things faster.

goodpoint 4y ago
bastawhiz 4y ago
> native containers wins If your threat model includes hardware bugs, then a container doesn't really help, no? You can't really trust your containers without sandboxing them, and then you're killing your performance anyway.
- _0w8t 4y ago
  Heavily sandboxed container has overhead of few percents. A hardware VM slows things down by 10-20% for a typical application. So even combining VM with a container will still be significantly faster than WASM.
  - bastawhiz 4y ago
    For the runtime, yes. But the cost of sending information into and out of a VM/container versus staying in the same process is costly, especially for small amounts of computation. And you're also comparing decades of VM and container investment to a handful of years of investment in WASM. WASM code today will run faster by a huge margin in a few years as the compilers improve. But moreover, most folks don't care about hardware bugs letting untrusted code break out of a sandbox. Bugs have been letting code break out of VMs, even, for years. If a hardware bug is discovered, you install the microcode update or kernel patch and move on. Which is to say, the performance isn't the reason for choosing WASM. It's good enough, in many cases. Being able to write a hundred or two lines of code to get pretty-fast and pretty-damn-secure sandboxing without needing to waste your time setting up and maintaining an elaborate breakfast machine of VMs and containers is the draw.

oxff 4y ago

Docker doesn't even .. really fix the issue it claims / is-used-for. I think nix does that, but it's pure pain to use. But it does actually address IME the repro issues.

OJFord 4y ago

> [...] take a look at WebAssembly as the 'successor' to containers and the next logical step in infrastructure deployment [and so on about containers] 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.?

paulgb 4y ago
It seems this is replacing both, in that the wasm module is not run inside of a traditional linux container (at least as far as cgroups go). > Each traditional container gets its own control group as in docker/ee44.... On the other hand, Wasm containers are included as part of the podruntime/docker control group and one can indirectly observe their CPU or Memory consumption.

jeroenhd 4y ago

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associated with that, but leveraging virtual machines instead solves that issue. There are already proof of concept implementations to replace Docker with VMs as a virtualisation layer, so I wonder if it wouldn't be better to invest time in getting those wrappers completely up and running rather than coming up with essentially "Java but we also emulate the OS". Until WASM advocates start including benchmarks in their blogs, I'll keep watching this stuff from a distance.

et1337 4y ago
The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.
- moss2 4y ago
  > This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.
  - hermanradtke 4y ago
    This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
    - koonsolo 4y ago
      On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

solomatov 4y ago

Does anyone has any links to recent benchmarks which show how large is the gap between WASM and native code? In theory WASM looks really great, but the last time I looked at it, the gap was big enough to be a concern.

kllrnohj 4y ago
The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting. Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the price of portability after all.
- solomatov 4y ago
  But how large is this gap? I.e. 10%, 50%, 100% or 1000%. Size of this gap affects trade offs of using WASM vs native code a lot.
  - TUSF 4y ago
    It varies by the runtime, and the codegen of the WASM itself. From some benchmarks & anecdotes I've seen, the faster runtimes (v8, Spidermonkey, WAVM) are within about 10-50% of native speeds, give or take. There's also some runtimes (like Wasmer & WAVM) which provide the option to AOT compile your WASM module to native. In those cases, the gap from native is much smaller. But so far the JIT for WASM is just immature. That said, from what I've read, it looks like starting up a new WASM instance is pretty fast, so some places are using it for when they need to spawn up tons of instances all at once, without having to wait for a whole process to warm up.

Havoc 4y ago

Is there a way to do this from CLI already? Or still desktop only feature?

deleted 4y ago

[deleted]

nashashmi 4y ago

I once imagined a time in a far, faraway land where the new OS secretly in development was nothing more than a thin interface between the hardware and the software. And the software was a VM. And this was codenamed Fuchsia. And was being worked on by Google. They took away the lessons learned from CHromeOS with its LXC containers and Android Container. And realized the new OSs of the future can be anything and everything for anyone and everyone. And opening 35 applications meant running 35 different VMs made of 17 unique OSs and this was called a software's full-stack. And then I would check the memory usage only to be horrified my 128 GB RAM was nearly full, and RAM was just not enough. Then I snapped out of this nightmare. Are we intentionally not thinking about RAM usage in this dystopian world where we celebrate WASM-Docker progress without thinking of the drawbacks: memory inefficiencies?

angelmm 4y ago
Actually, Wasm goes into the direction you are pointing. A Wasm runtime should add a little overhead to the requirements of the Wasm module. However, it's true Wasm is not on that point yet. There are open threads about deallocate Wasm memory [1]. However, I expect these features, as well as Garbage Collection [2] will come to the stardard over time. This will allow modules and runtimes to properly manage memory usage. [1] https://stackoverflow.com/a/51544868 https://stackoverflow.com/a/51544868 [2] https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc
- cma 4y ago
  If I run two programs with the same shared libraries, the nonrelocated parts are not duplicated in memory (and if I fork, the relocated parts aren't either). Does wasm map shared memory from disk like this, for the translated executable code?
klabb3 4y ago
Fuchsia natively does not use VMs for isolation (although there might be some compat effort that tries to do that). In fact, fuchsia is shipped to one of the lowest-end devices on the market - an old gen smart display. It also uses content addressable FS to deduplicate shared deps. Remember, nightmares aren’t real.

nikeee 4y ago

One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to. If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff from V8 for that. Any idea why they did not include these kinds of permissions in the WASI standard? It seems like WASI was not designed to be run without some sandbox.

pie_flavor 4y ago
No, you are not getting this right, and these permissions are built into the WASI standard.
angelmm 4y ago
That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking. For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With this, you can give access to a folder to a module and that module may call another one without giving them those permissions. In other ecosystems, any library used by the "main" logic gets the same permissions.
- cma 4y ago
  Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?
  - agent281 4y ago
    You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.

jensenbox 4y ago

I stopped reading once I saw the article was targeting PHP. I am sure this is a great technology but really hard to see the benefit over standard docker. Does anyone have a pro/con list for docker and wasm at the server? Is there a "Use Docker when..." or a "Use WASM when..." style guidance?

enriquto 4y ago

If you are going to recompile everything statically into a new target, why don't just build an αpε? It seems like a more elegant and clean solution.

spullara 4y ago

AWS Lambda SnapStart makes all these alternative, constrained serverless systems look pretty painful for little gain. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html

alzaeem 4y ago

How is it possible that the image size is so much smaller with the WASM image compared to the Docker image? They need to ship the entire php runtime compiled to WASM, so I don’t see how it can be smaller

the_gipsy 4y ago
What do you think is in the docker image?
- alzaeem 4y ago
  They showed the WASM image is 5mb vs 30mb for the alpine Docker image. So that’s 25mb of overhead due to the alpine distro?
  - the_gipsy 4y ago
    That could be the main factor.

jbverschoor 4y ago

So what's the purpose of Docker according to Docker? Reproducible builds, consistent dev environments? I always thought it was to have production and development environments the same, but these statements contradict that.. Unless they expect you to run WASM on your servers..

vlunkr 4y ago
> Unless they expect you to run WASM on your servers They do, this is an emerging idea. > I always thought it was to have production and development environments the same This seems to be the first thing many people try to do with Docker. IMO it's actually not a great experience. In dev, you need to make changes, in prod, you shouldn't, so they're not the same at all. Docker has many strengths: reproducible builds, consistent deployment strategies(k8s doesn't care what's in your container), a consistent DSL for building apps, The ability to extend a huge collection of other Dockerfiles to get what you want. I'm sure there are more.

tinyspacewizard 4y ago

This totally missed the point. I use Docker where the compilation story (and cross-compilation story) is a mess (looking at you, Python) and I don't have the resources to figure it all out. With Docker, I can get a portable image working in a few hours. It's a hack, but it's a convenient one. WASM does not offer this.

b33j0r 4y ago
It’s people who see the potential of this emergent technology getting prematurely excited. It promises to neutralize the playing field like Java promised, and Docker. I’ve seen WASM do some cool shit, don’t count it out. Just factor in the irrational exuberance.
- quickthrower2 4y ago
  I am bullish on WASM because technical merits aside it is in the browser and so it will be widely used because everyone knows it will be widely used. JS now runs on or is a source everywhere for example: embedded, frontend, backend, edge, mobile. WASM will be the same. In addition with so many compile to JS technologies and chains, WASM is sort of another choice. Not a big deal for a team to choose it. I don’t know enough about will it replace docker. But a lot of docker use cases are a bit of a leaky abstraction over what you are trying to achieve. For example why do I need to know what Alpine Linux is in order to run a node app? OK there is a node image that hides this detail but barely, you end up having to think about this sort of stuff.
  - b33j0r 4y ago
    It’s pretty cool to write a 3D game in godot, and see a browser run it like it’s nothin. It answers the question “but can it run linux/doom?” easily. Does it have the marketshare to make AWS make significantly different decisions? Remains to be seen. I guess people paid money for serverless. Could go that way Edit: I never thought node.js would take over half of the information sphere, so read me more like a graybeard who is too young to be one.
  - 4y ago

moyix 4y ago

Is there some page or document that explains how this actually works from the point of view of a traditional container / UNIX process worldview? Like, have the WASM folks implemented an emulation layer for Linux system calls? For libc? POSIX? Or maybe you need to modify your traditional programs so that they use WASM APIs instead? Just very confused at the moment :) I get the core idea of compiling other languages to WASM, but at the end of the day they have to talk to the outside world somehow right?

peterhunt 4y ago
I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
- moyix 4y ago
  Aha! Thanks. :) So it sounds like it's a new capability-based syscall interface, but they've ported big chunks of libc (specifically musl) to that interface so that a lot of things work.
  - peterhunt 4y ago
    Yes, that's my understanding, but I've never actually used it :)

btbuildem 4y ago

"Docker without containers" -- proceed to build a docker container with wasm runtime inside. I don't think I get this.