+1 - I tried using GraalVM for a Clojure(script) + re-frame application recently and it didn't work, changing back to OpenJDK works fine. It's a shame because the times were Graal does work, the start-up time is orders of magnitude faster.
I've only done one project with GraalVM and I've been pretty happy with it in regards to faster startup time.
I was doing stuff in Clojure. Clojure is a great language but it tends to have very slow startup times, even by JVM standards (it's not weird for a large Clojure program to take 5-6 seconds to start. Even a "hello world" can take upwards of a second or two). Graal mostly Just Worked with the standalone uberjar produced by Leiningen and created an executable that started in about 3 milliseconds. It was amazing.
While the lack of proper reflection support was a little annoying, it actually wasn't as horrible with Clojure as you might think; most problems were fixed with basic type hinting, and all but one Clojure library I used (http-kit) worked flawlessly.
However, the elephant in the room (which I also like to ignore as a Clojure enthusiast) is that the start up time of a Java based GUI app is too slow (this is exacerbated even moreso when Clojure is involved)
I'm expecting a GraalVM rejoinder from someone. For anyone who's used GraalVM (particularly with Clojure) - what are the downsides and limitations?
Oh! That's a valid reason; I'm actually surprised that GraalVM has issues not supporting JVM features, since I've been using it for Clojure code locally (though admittedly just for fun, nothing serious). Definitely makes sense if you're stuck rewriting things anyway, might as well just do it in a more modern language.
I've been out of the Clojure ecosystem for some time now -- has GraalVM solved the slow start problem? I remember the 1-2 second start up time being a deal breaker for many applications.
Sometimes the trade-off of slow startup vs. having a JIT'ed VM is better, since you get a lot more performance, if you're working w/ long-lived processes.
As a side note, GraalVM is quite usable for real world stuff nowadays. Here's an example of running a Clojure web service with Graal that provides JSON endpoints, talks to the database, and does session management: https://github.com/yogthos/graal-web-app-example
The same app can be run on the JVM or compiled statically using Graal. The JVM version takes around a 100 megs of RAM, and has a significant startup time. The Graal version weighs in at 7 megs, and starts up instantly.
Hmmm,yeah I should really just try GraalVM. JavaFX finally supports it. I just remmeber it was a bit unclear how to hook it up with Clojure/deps.edn but I'm sure the tooling has evolved since I last looked
Some day they'll integrate cosmopolitan builds with Graal native and we'll come full circle to cross-platform executables haha
GraalVM is super exciting. Suddenly the major reason against adopting the JVM for certain use cases has gone away: start-up time. That said, I’ve spent a couple hours trying to get GraalVM to produce a native image of a moderately complex Scala project (20 kloc) I work on in my spare time, and can’t get it to work.
Would be nice because supposedly not only does GraalVM reduce start-up time but features some highly aggressive optimizations ideal for abstraction heavy code/languages (like scala). Would be nice to use because scala generates garbage like it’s no tomorrow.
GraalVM is really more like a very specialised JVM that can be used to spit out a native binary for any platform for which there exists a GraalVM version.
But in order to do that, it does some interesting things under the hood, and it doesn't play nicely with reflection by default (amongst other things). For some non-Java JVM languages that's a major problem since their compiler produces JVM byte code that relies heavily on reflection (Groovy is/was a great example of this). I'm unsure how much, if any, reflection Clojure relies on but that would be the most likely reason for it to struggle with GraalVM compatibility.
Cool stuff. GraalVM has been another to get make JVM Clojure apps cold start quickly. I guess when deciding between these the ergonomics of AWS APIs between the JS and JVM platforms would be a big consideration, anyone tried both and can report?
For me the most interesting part is how it gets rid of the JVM startup time.
So there are two parts to the solution: The first part is Small Clojure Interpreter (sci) which is a "(subset of) Clojure written in Clojure", so kind of McCarthy for Clojure. A cool project in itself but it still needs a VM to run.
So here is where the second part comes in: the GraalVM produces native binaries from various things, including Clojure code and SCI is simple enough to work with GraalVM.
It's cool how these two pieces of tech combine together to create something greater than the sum of the parts.
I don't love Java like I love Clojure but I think Java may stage a comeback with GraalVM: it has cut down startup times to almost match with native C/C++ . I am taking all my java projects meant to run on AWS Lambda and am running it through GraalVM to cut startups time and also memory size.
If you think that the JVM is icky, GraalVM may satisfy some of your concerns.
Just getting access to Clojure on Windows through a single graal executable saved me some heartache this week, and I can't wait to start packaging apps with it.
reply