← Back to context

Comment by bzzzt

6 days ago

We had that in the 90's with Java. Why would this approach succeed today?

Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.

  • You mean like the CLR?

    Kind of strange that such experience still allows for WASM to be the target of C and C++ compilers, and there is no bounds checking support inside linear memory regions.

WASM sandbox is miles better than the JVM

WASI is a standard on where to poke holes on the sandbox for your specific use-case

WASM+WASI as a compilation target allows any program written for modern operating systems to work on any WASM runtime

Because Java is a language, not a compilation target?

  • From the introduction section of the Java specification [1]:

    "The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs."

    [1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...

    • From the same link, opening sentence:

      "The Java® programming language is a general-purpose, concurrent, object-oriented language."

      Edit: Having thought a little, I appreciate that it's possible to compile for the JVM from source code which is not Java, which makes the JVM a compilation target. As far as I'm aware the JVM doesn't have first class support for this though, It's been tacked on as an afterthought. Compiling C to JVM bytecode for example doesn't appear to be an enjoyable process. WASM on the other hand was designed explicity to function as a compilation target for arbitrary languages.

      Maybe I'm missing something, happy to be proven wrong.

      2 replies →