Hacker News new | ask | show | jobs
by sumukh1 3814 days ago
This uses the Truffle framework and GraalVM. (http://openjdk.java.net/projects/graal/)

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

1 comments

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?
I don't know the answer to that, but currently they have: Java, JavaScript, C, Ruby, Python, R, and a simplified SmallTalk.
Thank you for the list. I really hope the VM can enable porting language runtimes that are not available in JVM, C#, Swift, Go...
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.