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?
A JavaFX hello world app starts in around 1 second on a modern computer. Here's a small demo of a self-updating JavaFX app where you can see it being started, then built again, then re-launched with the new version: https://github.com/renatoathaydes/keepup/blob/master/docs/im...
If the author's app takes 10 seconds to boot, I am afraid they need to blame either Clojure or their own code for that.
That is a common trend on JVM guest languages, to blame Java or the JVM for their impedance mismatch with the host platform.
Granted, this usually only comes from those that don't bother much to learn about the underlying platform and are sometimes even agressive against what actually made their favourite guest language possible to exist.
what actually made their favourite guest language possible to exist.
maybe i'm arguing semantics, but i don't think it's fair to say that the JVM "made Clojure possible" -- that's like saying "C made Python possible because CPython is written in C".
iirc the JVM was chosen as a backend because that's what Clojure's creator had to work/interop with. and i think that's generally the case with "guest" languages -- there's an environment you want to write code for (JVM/ browser), but you don't want to use its "official" language (Java/JS), so you create a new language and adapt it to run there.
and sure, reusing the Java stdlib and other existing code can help bootstrap a language, no doubt about that, but it's a stretch to say it makes it "possible"
Clojure's success lies in being a Lisp that takes advantage of the JVM libraries and JVM monitoring tools, without them it would be just yet another Lisp clone like so many others since the early 60's.
i guess i was being a bit pedantic... as you say, if you look at Clojure's whole programming environment (tooling, stdlib) and not just the language itself, putting it like GP did makes sense.
I'm building a TornadoFX app with Kotlin now and it also starts in about a second. Also there is FXLauncher ( https://github.com/edvin/fxlauncher ) which provides a native package and an auto updater for macOS, Windows and Linux.
This is a really cool usage of it: https://github.com/borkdude/babashka, but last I had checked, it didn't have any GUI integration, and installing the GraalVM to begin with is a very heavyweight install.
Yes I've installed babashka. It really is a cool project.
Must look into GraalVM at some point, but, as someone new to Clojure, I'm wary of spending too much time on tooling yet. I've found in the past I can tinker so much with such things that it interferes with getting fluent with more fundamental stuff.
I'd be interested to see if either now or in the future Clojure + JavaFX in GraalVM would be feasible.
Edit: I don't quite get the install size issue - I thought native image was an entirely standalone executable?
Comments
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?
A JavaFX hello world app starts in around 1 second on a modern computer. Here's a small demo of a self-updating JavaFX app where you can see it being started, then built again, then re-launched with the new version: https://github.com/renatoathaydes/keepup/blob/master/docs/im...
If the author's app takes 10 seconds to boot, I am afraid they need to blame either Clojure or their own code for that.
That is a common trend on JVM guest languages, to blame Java or the JVM for their impedance mismatch with the host platform.
Granted, this usually only comes from those that don't bother much to learn about the underlying platform and are sometimes even agressive against what actually made their favourite guest language possible to exist.
maybe i'm arguing semantics, but i don't think it's fair to say that the JVM "made Clojure possible" -- that's like saying "C made Python possible because CPython is written in C".
iirc the JVM was chosen as a backend because that's what Clojure's creator had to work/interop with. and i think that's generally the case with "guest" languages -- there's an environment you want to write code for (JVM/ browser), but you don't want to use its "official" language (Java/JS), so you create a new language and adapt it to run there.
and sure, reusing the Java stdlib and other existing code can help bootstrap a language, no doubt about that, but it's a stretch to say it makes it "possible"
Clojure's success lies in being a Lisp that takes advantage of the JVM libraries and JVM monitoring tools, without them it would be just yet another Lisp clone like so many others since the early 60's.
i guess i was being a bit pedantic... as you say, if you look at Clojure's whole programming environment (tooling, stdlib) and not just the language itself, putting it like GP did makes sense.
I'm building a TornadoFX app with Kotlin now and it also starts in about a second. Also there is FXLauncher ( https://github.com/edvin/fxlauncher ) which provides a native package and an auto updater for macOS, Windows and Linux.
How's TornadoFX in terms of 'lightweightness'? Presumably worse than Qt but still much lighter than Electron?
This is a really cool usage of it: https://github.com/borkdude/babashka, but last I had checked, it didn't have any GUI integration, and installing the GraalVM to begin with is a very heavyweight install.
Yes I've installed babashka. It really is a cool project.
Must look into GraalVM at some point, but, as someone new to Clojure, I'm wary of spending too much time on tooling yet. I've found in the past I can tinker so much with such things that it interferes with getting fluent with more fundamental stuff.
I'd be interested to see if either now or in the future Clojure + JavaFX in GraalVM would be feasible.
Edit: I don't quite get the install size issue - I thought native image was an entirely standalone executable?
The GraalVM system/tooling itself, for generating native code from JVM was a big download/install - the generated binaries, I can't speak to too much.
Java has had AOT compilers since 2000, they just haven't been free beer for the most part, hence why FOSS keeps ignoring them.
Ironically they have to thank Oracle for doing something that Sun was religiously against, having an AOT compiler as part of the free beer Java layer.