I think Graal and Truffle are really great technologies. With a lot of potential to overcome unneeded silo's between programming language communities.
For example the project I work on has a website that has been continuously improved for over ten years. This means that a large part of our stack is still JavaServletPages and not everyone enjoy's working with it. The backend is pure Java and we can't afford a complete rewrite. And a microservice architecture doesn't make sense (it really just 2 people full time on frontend with 2-4 others contributing once in a while)
So we are working on using a modern ES6+ approach to replacing JSPX templates with functional style JS code for rendering. Basically a bunch of sed/xpath to do a rough translation and then execute it with either Nashorn (after babel at the moment) and soon graal.js.
Hopefully, giving our frontend devs a modern stack without incurring the costs of doing a lot of extra HTTP APIs.
At the same time it would allow us (even more pie in the sky) to include some snippets of C code that would implement a nice function that we could call in the webserver if some input data is small. Avoiding reimplementing this in Java would be nice, especially as the C code is SIMD aware. Currently we send all data off to an external service, but that has significant overheads in communication and polling that would not be needed for small input data.
I'm really excited about the Graal model and especially Graal.js.
Here's hoping for a world where Graal.js is released as open source and runs on an official JDK release! Then we can do all sorts of wizard magic with JS in the cloud, without running actual Node. I tell myself it could be any year now. I forget whether JDK 9 supports Graal and what the latest release date for 9 is; it's changed so many times. I know there was some indication that Graal.js would eventually be open-sourced, but that may have been taken back.
After digging into Graal and Truffle I was really impressed to learn what its vision is and what it is capable of. Then I discovered the Eclipse OMR project, and while the later is written in C++, they sounded like they have similar goals. I'd love to hear someone with more information compare and contrast these projects.
A few years back the Graal compiler from Oracle caught my attention as it was able to accelerate ruby code on the JVM with incredible results.
However it was not able to support any real world code / frameworks— ie. Rails.
(At the time I even downloaded the compiler myself, but it was quite experimental)
We're not done yet, but we do pass, for example, 100% of the specs for ActiveSupport and ActiveModel. Most of the other parts of Rails need database drivers, and that's what we're fixing with these C extensions.
The self-rewriting interpreter model is so so interesting, and has already proven itself in things like peak performance, and cross-language. However, it can have the disadvantage of blowing up warmup time. Are there Truffle language impls that persist their specialized interpreter nodes across executions?
For example the project I work on has a website that has been continuously improved for over ten years. This means that a large part of our stack is still JavaServletPages and not everyone enjoy's working with it. The backend is pure Java and we can't afford a complete rewrite. And a microservice architecture doesn't make sense (it really just 2 people full time on frontend with 2-4 others contributing once in a while)
So we are working on using a modern ES6+ approach to replacing JSPX templates with functional style JS code for rendering. Basically a bunch of sed/xpath to do a rough translation and then execute it with either Nashorn (after babel at the moment) and soon graal.js.
Hopefully, giving our frontend devs a modern stack without incurring the costs of doing a lot of extra HTTP APIs.
At the same time it would allow us (even more pie in the sky) to include some snippets of C code that would implement a nice function that we could call in the webserver if some input data is small. Avoiding reimplementing this in Java would be nice, especially as the C code is SIMD aware. Currently we send all data off to an external service, but that has significant overheads in communication and polling that would not be needed for small input data.