Thanks! Out of curiosity — if I built an application with truffleruby, could I distribute it as a JAR (provided that it was run under JDK 9)? Are there ways to call out to Java like JRuby? Having some difficulty finding documentation around this.

> if I built an application with truffleruby, could I distribute it as a JAR

Yes there is a Java embedding API.

http://www.graalvm.org/docs/graalvm-as-a-platform/embed/

> (provided that it was run under JDK 9)

It can run on 8. It'll be fast on JDK 9 or 10 because these have the interface to use Graal.

> Are there ways to call out to Java like JRuby?

JRuby compatible interop:

https://github.com/oracle/truffleruby/blob/master/doc/user/j...

Our own interop:

https://github.com/oracle/truffleruby/blob/master/doc/user/p...

> Having some difficulty finding documentation around this.

https://github.com/oracle/truffleruby/tree/master/doc

Be warned, the jruby compatible interop isn’t complete, and I don’t have the jruby test suite running for it because that requires a much more complete implementation to run at all.

It’s good for quite a lot though.

Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?

It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application.

It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.

Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program?

Will this be the case for truffle python, js,etc ?

I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs.

The problem is that the semantics of Ruby are such that you can't compile it efficiently out of the box. TruffleRuby can but only by making tons of assumptions at runtime that might not be valid. So it compiles code on the assumption your program is normal and not weird, and if those assumptions are violated, it goes back to interpreting the source code.

Therefore even if you could pre-compile Ruby in some pedantic sense, you'd still need the source code to fall back to when the JITC has to bail out.

That's partly true, but depends on the particular program. There are Ruby programs that could be compiled ahead-of-time quite efficiently, despite their dynamic features.

The slow-path version of the code that violates runtime assumptions can still be compiled as an alternative variant - so instead of switching from fast compiled code to the interpreter, the code violating the assumptions can switch to slow-path compiled code.

While that's true, and switching to a slower path solves many problems, consider this common Ruby pattern:

    Dir.glob("some dir/*").each do |filename|
        require filename
    end

A lot of Ruby code messes with how code is loaded (heck, "require" in almost every Ruby install is not the built in "require" but one that has been dynamically replaced). Sometimes that is intended to implement static behavior: The expectation is that the code remains the same. It's just a way of avoiding having to maintain a list manually.

But other times it is used as a plugin mechanism, where the expectation is for the code to be provided by a user or other developer, and processing this statically at compile time would remove capabilities that the user would expect.

You can't automatically determine things like that, because it is down to developer intent and the code does not document the intent.

So the problem goes deeper than being about being able to revert to a slow path: To compile Ruby in a meaningful way you need to make some level of trade-off in what aspects of Ruby you decide to treat as "ahead of time" vs runtime, because there is no clear rule that says "now the program has been loaded; everything after this is runtime".

> Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program?

I would think that the fact that Ruby constructs that look like what would be compiler directives in a more static language (e.g., Ruby's “require” vs C’s “#include”) have their semantics defined in a way which both depends on and affects runtime state means that AOT compiling Ruby in the strict sense gets you very little, whereas running it to a certain point AOT and saving the runtime state gets you closer to what you'd expect from compiling based on usually-compiled languages.

Yes you will be. But we use a different interface. Checkout this guide: http://www.graalvm.org/docs/reference-manual/polyglot/

Select your start and your target language and it will show you an example. Its a very basic example, but it basically works with all Java types. We will provide better docs soon.

We do have a partial implementation of the jruby API, though I don’t believe it works on substratevm due to reflection.

How would I go about creating a native image for a gem I've installed? I can't seem to find the documentation for this.

Or have I misunderstood this totally? I thought I could do something like ruby script -> graal ruby --> jvm bytecode --> native image

Update:: Doesn't look like I read it wrong - from this reddit comment[1] from 3months ago

Ahh, I think there's some confusion here. What we do with the SVM is ahead of time compile the TruffleRuby interpreter, not an application. This is akin to what you'd do with MRI. Instead of treating Java as a language you compile to a .class file and load with the JVM, the SVM's native image generator compiles it to a native binary.

There's likely no reason we couldn't compile Ruby applications into a static binary.

I would also love to be able to distribute a ruby binary as a single statically compiled executable. Any pointers/directions?

[1] https://www.reddit.com/r/ruby/comments/7o3wy9/graals_substra...

> There's likely no reason we couldn't compile Ruby applications into a static binary.

I think this was a theoretical observation.

What is more likely in the near future is to be able to initialise your Ruby gem at compile time, so when you start your application it is already required and you can start execution as if all your require statements had already run.

Can GraalVM target the browser?

We did have a proof of concept JavaScript backend in the past but it’s never been public.

Is there a way to create a native binary using a main within jar and it's dependencies?

Yes just run `native-image -jar foo.jar`.

I am so super happy about the graaljs license choice ! Thank you so much!

This is actually the first time I heard of UPL, which from what i read in the FAQ [1] is basically a GPL v2 compatible Apache 2 license. Which was one of the problem Apple had with LLVM i think. I wonder why Apple decide not to use UPL?

[1] https://oss.oracle.com/licenses/upl/#_What_is_the_1

>GraalVM is available as Community Edition (CE) and Enterprise Edition (EE). The current release is based on JDK 8.

Why is this ? We are currently on JDK 10. Also - why is there no official Graal Python ?

I think Java 8 is the current LTS release isn’t it? Graal needs a stable platform to build on.

And there is an official Python alongside the other languages.

Can it also target bytecode or .jar artefacts, this way all JVM languages which compiles into JVM bytecode can be benefited

Yes, GraalVM is built on HotSpot so it can run all bytecode languages too.

Cool thanks. Keen to try it with Scala and Clojure. Curious to know, How effective would be it's JIT compared to HotSpot ? Any pointers ?

There are research papers that discuss this. It depends a lot on the bytecode patterns. For Java it's usually as good as the current JITC unless you're relying heavily on auto vectorisation. For Scala it's about a 10% win on open source or a 20% win for enterprise Graal, according to Twitter at least.

For Clojure I don't know. But from what I understand Clojure produces quite inefficient bytecode, so it may benefit a lot.

Why is this yet another implementation of Python? If C is supported why not use CPython itself?

Because Graal.python will be a lot faster. Just running cpython on GraalVm is possible but does not get you anything.