grashalm01

My rule of thumb: use checked exceptions if and only if your exceptions are not supposed to be rethrown and must be handled by the caller directly. These cases are very rare, but I recently had one them.

Exapunks is to programming as piano tiles the mobile game is to playing a real piano.

Graal can run in dynamic and aot compilation mode. If you feed profiles into aot from a test run you can get pretty close to dynamic compilation peak performance.

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

You will like to hear that there is some rstudio integration in the works.

Here is the correct link: http://www.graalvm.org/docs/reference-manual/compatibility/

(Accidentally posted the internal link :D)

Not yet. It's on our roadmap.

We have lots of infrastructure depending on mx. Infrastructure that no other build tool provides as far as I can tell.

In the end every build tool sucks. Sometimes you just need to be pragmatic. Mx integrates with maven pretty well and it generates ide config for intellij, eclipse and netbeans. Moving to a different system is probably not worth the cost atm. And it's not complicated to use at all. E.g mx build builds and mx gate builds and tests. Mx unittest runs unit tests.

As written below. Graal.Python is not yet open source. But you will hear from us soon.

I'm sure you will hear about us when we go open source with Python.

When executing on Java we are dependent on hotspot to support it in the native bytecode interpreter. In truffle interpreters we made some successful experiments with tail calls emulated using exceptions. It's pretty slow in the interpreter but as soon as graal optimizes it, it just turns into a tailcall loop. Here is some more info: http://epub.jku.at/obvulihs/content/pageview/508465

You may find some blog posts about truffle and tailcalls as well.

It started as fork of Zippy. It changed very much since then. You can download the binary as part of graalvm. It's not yet open source, but it will be. It's just not ready yet.

Good idea. The name is not final.

Graal dev here. We're testing on jdk 8,9,10 and 11. We are packing graalvm with jdk 8 atm to keep variability reasonable. Graal will be integrated into the JVM soon with project Metropolis: http://openjdk.java.net/projects/metropolis/

Graal is used for many more things than dynamically compiling Java. Besides others it's used for SubstrateVM (closed world AOT compilation) and Truffle languages like TruffleRuby, Graal.JS, FastR, Sulong(llvm integration) and our newest member Graal.Python.

Graal comes out of Oracle Labs. The build tool mx is short for Maxine, the spiritual predecessor of the Graal project. If you don't know mx it's quite intimidating and ugly. It's Python written by Java developers. But it does it's job coping with our not so standard building and testing requirements. No we don't run mx on Graal.Python yet, but we are working on it for full build tool metacircularity ;).

Didn't they say in the end that c9.io will continue to work?

I've played enough factorio to know that you only need one person. Also handling the rail system at the same time.

Factorio does an amazing job teaching programming concepts without even noticing.

Your mission seems to be matching with what we are trying with Graal and Truffle. The Truffle API aims to be stable as well. We also provide basic building blocks like an object model. I am curious how you plan to support speculative optimizations that need to deoptimize and reconstruct interpreter stack frames? In my experience that's essential for building high performance dynamic language implementations.

Great. By compromising one package you can access their bank account...