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.

I think that's a reasonable rule of thumb, and it tends to be the way I use checked exceptions as well.

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.

And if you don't the gap is about 20% iirc.

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)

Awesome, thanks for that. I'll definitely give it a shot once rstudio is supported.

Not yet. It's on our roadmap.

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.

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 ;).

Vendoring the JDK is a much better use of resources than chasing compatibility, esp for a research project.

Is Graal.Python related to Zippy [0,1] ?

[0] https://github.com/securesystemslab/zippy

[1] http://socalpls.github.io/archive/2013nov/slides/zippy.pdf

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.

I've been watching zippy for a while, unfortunately it relies heavily on Jython which is dead. Would be very interested to see progress on this! (And maybe contribute as well!)

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

Hi - thank you so much for posting here. Please please get rid of MX. Please move to a better build tool - you will pull the ecosystem with you. And people will help you with that.

Secondly - I have not seen Graal Python anywhere. Is there a repo ? The GitHub project seems centred around Truffleruby. Graal Python would be awesome!

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.

Any story behind why it's not open-source ? I mean Ruby, Js, R seem to have been for a long time.

Any splashy announcements expected?

p.s. sorry to be pushy. I have a long standing python-and-reactjs-on-java-in-2018 bet !

They tend to work in private then open source later.

Why not Graal.py?

For me this would mean a python project (graal bindings within CPython) and not a Python implementation.

CPython Pypy Jython IronPython

I would now go with GraalPython (GrPython or GPython)

Graal.py rubbed me the wrong way, until I read your comment I couldn't put my finger on why. Thank you!

Its more symmetry with Graal.js

Good idea. The name is not final.

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

It works if you already have an account. I think anyone who watches one of my videos from today forward is out of luck.

What's stopping you from setting up your own c9 setup since it is open source?

Probably because he/she has tons of videos that walk through setting it up on c9.io's old site.

I'm also a course creator (but I don't use cloud9). A change like this is a really big deal for someone in his/her shoes. Having to re-record all of those videos is non-trivial, and doing it with the self hosted version would still require new videos to be made.

I'm not saying it isn't a hassle. But that is a better solution then rerecording everything. If you come up with a self hosted solution for c9, I would hope that the courses have a single video for setting up cloud9 which would be better then rerecording everything.

I feel for them, but it is the risk associated with using any sort of product you don't directly manage yourself.

This. Yes.

Consider Eclipse Che and CodeEnvy.

You can version pin/host/containerize to self host, whatever, along with sharable prebuilt envs.

For how long, is the question...

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