7 ms·

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

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