4 ms·

Long JVM startup time is a big reason why I went with Elixir instead of Clojure when I decided to move off Ruby to do webdev. (Another reason was easily trigger

Long JVM startup time is a big reason why I went with Elixir instead of Clojure when I decided to move off Ruby to do webdev. (Another reason was easily triggering nasty Java stacktraces.) My Elixir test suites fire up instantly and finish in seconds (if that) and this fast-as-possible feedback loop is extremely important to stay productive, IMHO.

lastofus 8y ago
The editor based REPL is how the Clojure folks stay productive (as opposed to running tests at the command line). Using a keyboard shortcut to eval any expression in your code is really great. The stacktraces are still often terrible though =/
pron 8y ago
Clojure startup time is only partly related to JVM startup time, which is ~60ms[1][2]. The reason Clojure startup is slow is because Clojure requires a very elaborate initialization. OTOH, the Erlang VM (BEAM) is much, much, much slower than the JVM (Hotspot, at least). [1]: https://blog.ndk.io/clojure-bootstrapping.html https://blog.ndk.io/clojure-bootstrapping.html [2]: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/
- dman 8y ago
  Cant you just have a system clojure process started up and then fork from there?
  - pron 8y ago
    Forking, in general, is not a very safe operation when the process is an elaborate one, like a JVM. It may, however, be possible to have Graal compile the Substrate VM image for Clojure after the initialization has been done, dumping the initialized state to the image, and then just loading it on launch. This may be the solution chosen once Graal matures a bit, and people learn how to use it well.
  - pmarreck 8y ago
    Forking is easiest and safest in a functional-data-structure immutable language (where it's basically trivial). Mutable languages? Not so much.
jimmyhmiller 8y ago
With Clojure you get that feedback loop by running everything in an open repl. No startup time needed.
- pmarreck 8y ago
  so you rerun tests in a REPL? what happens when something is redefined?
  - yogthos 8y ago
    Typically Clojure apps are structured to be reloadable meaning that you don't have any global state, and you can easily flush the current REPL state http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... There are also tools like lein-test-refresh https://github.com/jakemcc/lein-test-refresh https://github.com/jakemcc/lein-test-refresh that figure out what needs to be reloaded automatically. You start it up, it watches your namespaces for changes, and reruns tests as needed. As a bonus it can even hook into your OS notification system and let you know if any tests fail.
  - ilikehurdles 8y ago
    A lot of editor integration will handle reloading and test-running for you (including VSCode's calva extension, Cursive, and Proto REPL for Atom, although it's less "automatic" than the others).

lastofus 8y ago

The editor based REPL is how the Clojure folks stay productive (as opposed to running tests at the command line). Using a keyboard shortcut to eval any expression in your code is really great. The stacktraces are still often terrible though =/

pron 8y ago

Clojure startup time is only partly related to JVM startup time, which is ~60ms[1][2]. The reason Clojure startup is slow is because Clojure requires a very elaborate initialization. OTOH, the Erlang VM (BEAM) is much, much, much slower than the JVM (Hotspot, at least). [1]: https://blog.ndk.io/clojure-bootstrapping.html https://blog.ndk.io/clojure-bootstrapping.html [2]: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/

dman 8y ago
Cant you just have a system clojure process started up and then fork from there?
- pron 8y ago
  Forking, in general, is not a very safe operation when the process is an elaborate one, like a JVM. It may, however, be possible to have Graal compile the Substrate VM image for Clojure after the initialization has been done, dumping the initialized state to the image, and then just loading it on launch. This may be the solution chosen once Graal matures a bit, and people learn how to use it well.
- pmarreck 8y ago
  Forking is easiest and safest in a functional-data-structure immutable language (where it's basically trivial). Mutable languages? Not so much.

jimmyhmiller 8y ago

With Clojure you get that feedback loop by running everything in an open repl. No startup time needed.

pmarreck 8y ago
so you rerun tests in a REPL? what happens when something is redefined?
- yogthos 8y ago
  Typically Clojure apps are structured to be reloadable meaning that you don't have any global state, and you can easily flush the current REPL state http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... There are also tools like lein-test-refresh https://github.com/jakemcc/lein-test-refresh https://github.com/jakemcc/lein-test-refresh that figure out what needs to be reloaded automatically. You start it up, it watches your namespaces for changes, and reruns tests as needed. As a bonus it can even hook into your OS notification system and let you know if any tests fail.
- ilikehurdles 8y ago
  A lot of editor integration will handle reloading and test-running for you (including VSCode's calva extension, Cursive, and Proto REPL for Atom, although it's less "automatic" than the others).