I remember the researchers at Oracle mention in their presentation that not all languages can be ported to GraalVM. Do you know what language runtimes can and cannot be implemented on GraalVM?
Truffle is intended primarily to speed up scripting languages. It works with C too, which is impressive, but it does it by treating C as a scripting language and then aggressively optimising it until it's back to being as fast as what GCC would do. But for instance, you need the source code at runtime, like a script. You can't compile C to a bytecode file in a JAR like with traditional Java.
The issue with porting C# would be that C# exposes low level features that the JVM doesn't have, like value types.
Swift and Go probably could run on the JVM and Go in particular would probably benefit from it a lot. I've often thought that a Go for the JVM would make a nice little commercial project for a startup somewhere.
> It works with C too, which is impressive, but it does it by treating C as a scripting language and then aggressively optimising it until it's back to being as fast as what GCC would do. But for instance, you need the source code at runtime, like a script.
I think Graal can do AOT compilation (and optimization). The quality of the resulting code depends on the information it has at the time of compilation. So for C, as Graal has the same information as gcc, there is no reason it should produce any less optimal code than gcc, even when working AOT. The reasons for the current differences (so I've heard from the Graal team), is simply that they have not put in all the effort they can, but they have little doubt that Graal can match gcc when working AOT, and exceed it if run JIT.
I think that the decision of whether to treat a language "like a script" (i.e. rely on JIT compilation) or not is up to the language implementation. Graal supports both.
> You can't compile C to a bytecode file in a JAR like with traditional Java.
No (although you could in theory), but you can compile C (or Java) to a native binary with Graal. AOT compilation of Java to binary is how SubstrateVM works.
> Go for the JVM would make a nice little commercial project for a startup somewhere.
Sadly, there's very little money to be made in developing a programming language, especially if the language is not specialized for safety-critical and/or realtime applications.
The enterprise fizzbuzz does exactly what is asked of in the spec, allow room for expansion, split all responsibilities into modules which could be concurrently worked on by many different people/teams, and the testing ensures that miscommunication doesn't ruin a code base. In my books, that's clean.
Probably not yet. But I am sure that they are looking at this option that was used by JRuby+Truffle: http://chrisseaton.com/rubytruffle/cext/.
Where they use the same technique but then on C.
Although I heard that they will replace that approach with one where they directly work on LLVM IR instead. So that they can get all the LLVM supported languages in one go.
Related discussion about JRuby with Truffle: https://news.ycombinator.com/item?id=10817110
If anyone wants to get started with Truffle - I found these links helpful:
> 3 hour Intro + Tutorial: https://www.youtube.com/watch?v=N_sOxGkZfTg
> Blog Post Series: http://cesquivias.github.io/tags/truffle.html https://github.com/cesquivias/mumbler