What does HackerNews think of asmble?

> I was curious if there was a WASM to JVM and it seems there is one on GitHub [...] https://github.com/cretz/asmble

While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.

> "JVM requires almost all your stack to be rewritten for it."

This applies no more to the JVM than to Wasmer. There exists WASM to JVM bytecode transpilers [0].

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

Depends on what you mean by hoops (ala clang), but there is Graal which can run LLVM bitcode [0] but I am unsure if it can compile it. I have personally compiled C code to WASM and then to the JVM via [1]. C/C++ are complex (and/or have complex optimizations) so a compiler should be used, but doesn't necessarily have to target a specific CPU but still have to have a bit-preference and what not. And of course once you interact with the system, some abstraction has to occur somewhere.

0 - http://www.graalvm.org/docs/getting-started/#running-llvm-in... 1 - https://github.com/cretz/asmble

That line is labelled with https://github.com/cretz/asmble

Quite directly[0] :-) There's even an example using Rust regex on the JVM to get speedups in some cases [1].

0 - https://github.com/cretz/asmble 1 - https://github.com/cretz/asmble/tree/master/examples/rust-re...

> I'm so excited about WebAssembly, but really not because of the web.

You and me both. I wrote a backend for the JVM [0] and there is one in dev targetting native [1] (in Rust using an interesting alt-llvm project [2]). I suspect where you'll start to see this really shine is when a popular langauge targets WASM as the primary target and lets second-level backends compile to a specific arch. The other problem is interoperability. Until host bindings come along and the community standardizes on things like string representation and syscalls, many of uses are siloed by the frontend compilers. I think we can do better than libc+posix.

0 - https://github.com/cretz/asmble 1 - https://github.com/sunfishcode/wasmstandalone 2 - https://github.com/Cretonne/cretonne

Yup: https://github.com/cretz/asmble

Sorry I did not read it properly, you can use these ones instead to actually write WASM.

https://github.com/WebAssembly/wabt

https://github.com/cretz/asmble

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

In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble.