Some of the Cognitect veterans have pointed out that being able to connect directly to an instance and evaluating code at runtime has been invaluable for debugging issues for their clients.

However, I don't see a use case for GraalVM in long-lived server applications. For that, regular JVM clojure will do just fine.

On the other hand, using eval is almost never necessary in small standalone utilities.

> I don't see a use case for GraalVM in long-lived server applications

GraalVM also includes a better JIT compiler though, which makes long-lived applications much faster. Twitter use it today to run their Scala code.

From Twitter engineer Chris Thalinger's videos[0] it seems like they're using JDK 9 or 10 and graal via JVMCI. Is there more to GraalVM than just using graal with a particular JDK release?

[0]: https://www.youtube.com/watch?v=_7yIUkP5LiQ

> Is there more to GraalVM than just using graal with a particular JDK release?

Yeah there's a whole world of different ways you can use Graal.

https://medium.com/graalvm/graalvm-ten-things-12d9111f307d

They're choosing to use the JIT from CE Graal (which they've built themselves), via the released version of JVMCI in a released JDK.

agree but also, ClojureScript didn’t have runtime eval for a long time (because the compiler is bootstrapped on jvm) and that didn’t stop anyone. Even today, runtime eval costs sending all of clojurescript over the wire and no dead-code-elimination; cljs users are quite used to not having runtime eval in prod

to the point of pushing networked repl in core or near