Out of box compatibility with JVM about arua-meta HOT 2 CLOSED

Honestly, seeing as how both the JVM and LLVM just decompile to (effectively) C bytecode, I don't see why this wouldn't be possible.
Sure a type of interop package will have to be built and be able to run either alongside the main arua compiler (if it's built right into the compiler, then having an option to generate LLJVM bytecode or not). Or run it as a seperate service that reads the bytecode generated from the arua compiler then transpiles to LLJVM compliant code.

I'm not in favor of the transpiling option, yeah you gain compiler time and speed, but when you transpile from one thing to another without compiling natively? It can cause weird problems that prove a SoaB to solve.

Also something to think about.
it would be very useful to be able to cross compile Arua code as JVM and use JVM languages interoperably
I think this is a good idea, and bad idea.
It's a good idea because, you now have lots of portability options with Arua, you can move code easily from one JVM compliant language to the next. But! When you start adding more support for more JVM compliant languages this bogs down the language with lots of prepackaged support code, which can turn the language into a slow mess.
Now there's some ways I can think of too go around this, either A) Have "Packages" that are portability code for the language you want to cross-compile for... or B) Allow a compile time argument that will automatically download and link the language package.
But if you build it into the language? The language could get huge with any X languages you want to support.

from arua-meta.

I'm closing this as rejected. This was an awful idea and totally outside the scope of Arua.

from arua-meta.