Hacker News Reader

Comment by kodablah | Hacker News Reader

I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of course but as GC and threading specs come along, I can hope one day it will reach parity. Granted it isn't as low level, but that has benefits for compiler backend implementers (they can choose how they target their arch) and compiler frontend implementers (they don't have to do different things per platform). Basically, imagine if Java bytecode was developed less around OO semantics, wasn't lumped in with its stdlib by the community, didn't have encumbered JCK and other tests, etc, etc.

Edit: Changed "LLVM" to "LLVM IR" to clarify as requested.

View on HN

To me, this is the most exciting prospect of WebAssembly by far: an IR that works natively across all major platforms, including the web. It's funny because it makes Gary Bernhardt's "The Birth & Death of JavaScript"[1] seem a lot less like a joke.

[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I'm not sure your criticisms of Java bytecode are all that reasonable to be honest.

You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages.

Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC.

Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation.

Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.

> Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.

There are already projects to implement WASM in other contexts beside the web--some even in production. The specification, which has been entirely mechanized with an implementation of a provably-correct interpreter in Isabelle, is designed to be implemented easily. We welcome other implementations of the core execution spec of WASM and other embeddings. I can only speak for myself as a co-founder, but I believe most people involved in the W3C groups hope the scenario laid out in this comment does not happen in reality.

Yes, but all those things are true of other platforms as well. The JVM's type system has been proven correct. Everyone who writes specs designs them to be easily implemented (in their view) and everyone hopes the spec won't be forked by vendors or end up with widely deployed but buggy implementations.

The worst case scenario for wasm or any spec author is that someone comes along and either implements it very poorly, or adds vendor extensions that effectively become de-facto standards. E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features. And then people start claiming they've got a wasm module, but it doesn't work properly or well enough on other implementations.

That's what happened to the web, to Java and others, and is one reason why the TCK is "encumbered", as the OP put it. It's also why Android requires you to pass an encumbered test suite to be able to use the trademark/logo/get access to the Play Store etc. It's not like one path is inherently superior to another. Protecting a trademark by licensing the test suite and mandating it be passed is about risk management.

> The JVM's type system has been proven correct.

I'm not sure which proof you are referring to, but the Java and Scala languages both have unsafe type systems:

https://2016.splashcon.org/event/splash-2016-oopsla-java-and...

(Admittedly this is due to parametric types which are erased).

The JVM bytecode verification algorithm is over 100 pages in the spec.

> E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features.

We aren't doing that currently. We plan to continue participating in the W3C processes which have worked well over the past 2+ years.

I'm talking about the JVM type system, not Java's. They're not quite the same due to generics erasure and a few other things.

We aren't doing that currently

All browser makers have long histories of forking the platform with proprietary extensions more or less whenever they feel like it. So what does this assurance mean? Indeed that's now how HTML5 is meant to evolve! Nobody even uses the W3C anymore do they? It's all just throwing whatever extensions get built by browser makers into HTML5.

I'm sure WebAssembly will have its share of compatibility matrices and vendor-prefix equivalents soon enough.

The thread's a bit old, but I'll reply anyways.

> Scala, Ceylon, Clojure provide their own stdlibs.

On top of the JVM ones when targeting the JVM. E.g. java.lang.String (Kotlin too)

> You can write non-OOP programs in Java bytecode

Everything is still an object and all code is in methods. There is no way around that. Also, there are many other things like forced GC and what not that marry the bytecode to certain paradigms.

> it's about ensuring that if someone claims they run Java bytecode, they actually can run it.

And about their impls of java.lang and other base packages. And a way to make sure that licenses that Oracle doesn't like, such as non-OpenJDK-derived open source stdlib impls, are not given the tests. Other languages with compat tests publish them for all and yet aren't worried about losing their name. This is dangerous reasoning to apply to keeping things opaque.

It isn't just those big companies implementing WASM. I implemented a WASM backend for the JVM [0]. The core test suite, which I use and comply with 100%, is available to all [1].

0 - https://github.com/cretz/asmble/

1 - https://github.com/WebAssembly/spec/tree/master/test

Your comment was confusing to read. I think it would be easier to understand if you replaced "LLVM" with "Intermediate Representation".

This use case is interesting to me too. I looked into this a few months ago and found that there is a page on non-web embeddings:

http://webassembly.org/docs/non-web/

Reply on news.ycombinator.com