4 ms·

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 Interprete

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.

auganov 6y ago
A slightly simpler explanation: GraalVM solves the startup time but clojure's built-in eval wouldn't work after compilation so you need to reimplement it in a simpler way.
- michaelsbradley 6y ago
  Are you certain that’s the case? See: https://github.com/BrunoBonacci/graalvm-clojure#readme https://github.com/BrunoBonacci/graalvm-clojure#readme
  - fulafel 6y ago
    That's a table of library compatibility w/ GraalVM, one reason for incompatibility can be use of runtime evaluation.
    - tincholio 6y ago
      I think it's related to dynamic loading of classes (and since Clojure functions get compiled to classes, this might be the issue), not really evaluation per se. But I haven't really looked at Graal native image for a while, so I'm not sure what's the current status.
invisiblerobot 6y ago
The startup time of the jvm is negligible. This myth keeps coming up. Most of the startup time is Clojure itself.
- outworlder 6y ago
  This high startup time in Clojure is a side-effect of the JVM. If you have a hello world program that does nothing it is indeed fast. If you are running Clojure you need to run at least clojure.core. Loading that is handled - surprise - by the JVM. As would be expected, if you run other implementations (like Dalvik), this can change dramatically (for worse, usually). So it is correct that loading the JVM itself is not what's taking most of the time. But loading take so much time because of the JVM. https://blog.ndk.io/clojure-bootstrapping.html https://blog.ndk.io/clojure-bootstrapping.html
- lilactown 6y ago
  Whenever "Clojure startup time" comes up, people are quick to point to one thing: either it's the JVM "bloat," or that it's nothing to do with the JVM and is actually all Clojure. Here's a pretty good (if a bit outdated) analysis on Clojure startup time: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/ The question is, could Clojure be rewritten in a way that loads significantly faster with the same behavior on the JVM? I'm not sure. And especially on big projects, the lack of DCE on the JVM can lead to loading a ton of useless code that significantly impacts startup time outside of the Clojure language.

auganov 6y ago

A slightly simpler explanation: GraalVM solves the startup time but clojure's built-in eval wouldn't work after compilation so you need to reimplement it in a simpler way.

michaelsbradley 6y ago
Are you certain that’s the case? See: https://github.com/BrunoBonacci/graalvm-clojure#readme https://github.com/BrunoBonacci/graalvm-clojure#readme
- fulafel 6y ago
  That's a table of library compatibility w/ GraalVM, one reason for incompatibility can be use of runtime evaluation.
  - tincholio 6y ago
    I think it's related to dynamic loading of classes (and since Clojure functions get compiled to classes, this might be the issue), not really evaluation per se. But I haven't really looked at Graal native image for a while, so I'm not sure what's the current status.

invisiblerobot 6y ago

The startup time of the jvm is negligible. This myth keeps coming up. Most of the startup time is Clojure itself.

outworlder 6y ago
This high startup time in Clojure is a side-effect of the JVM. If you have a hello world program that does nothing it is indeed fast. If you are running Clojure you need to run at least clojure.core. Loading that is handled - surprise - by the JVM. As would be expected, if you run other implementations (like Dalvik), this can change dramatically (for worse, usually). So it is correct that loading the JVM itself is not what's taking most of the time. But loading take so much time because of the JVM. https://blog.ndk.io/clojure-bootstrapping.html https://blog.ndk.io/clojure-bootstrapping.html
lilactown 6y ago
Whenever "Clojure startup time" comes up, people are quick to point to one thing: either it's the JVM "bloat," or that it's nothing to do with the JVM and is actually all Clojure. Here's a pretty good (if a bit outdated) analysis on Clojure startup time: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/ The question is, could Clojure be rewritten in a way that loads significantly faster with the same behavior on the JVM? I'm not sure. And especially on big projects, the lack of DCE on the JVM can lead to loading a ton of useless code that significantly impacts startup time outside of the Clojure language.