6 ms·

I also worked this way, I've had REPL sessions that ran for months, but IMO this is a workaround rather than a real solution. It's a good workaround, but fast s

by synthc 4y ago

I also worked this way, I've had REPL sessions that ran for months, but IMO this is a workaround rather than a real solution. It's a good workaround, but fast startup would be a game changer. If Clojure would start fast enough, projects like Babashka would not be needed.

seancorfield 4y ago
It's not a workaround. It's how Clojure is designed, around its REPL, intended for interactive development at its core. Start a REPL, connect your editor, develop. You can start your apps in the REPL (from RCFs in your code -- Rich Comment Forms) and never type into the REPL. You can grow the application while it is running, you can run tests via the REPL from your editor. That interactive approach -- working on your application "live" essentially -- is what sets Clojure's REPL apart from other languages' "interactive consoles" (sometimes misleading also called REPLs :) And, yes, Babashbka is great for running CLI scripts. But that's a completely different use case to a long-running development process.
- synthc 4y ago
  I'm very familiar with the live editing aspect of Clojure, and I like it a lot actually. What I am saying is that Clojure's long startup time is still annoying if you want to restart, for example if you trashed your repl session or want to start with a clean slate. If Clojure would start fast enough it could also be used for CLI scripts and we would not need Babashka at all. All in all, I think Clojure is a great language, but the slow startup time is still a disadvantage.
  - jeff303 4y ago
    Wait, how slow is it starting for you? On my 2012 Mac Mini, a clean clj 1.11 REPL (with no namespaces loaded) starts in under 5 seconds (using JDK 18).
    - synthc 4y ago
      No namespaces loaded is not a very good benchmark IMO, a real project will have lots of them. I've worked on a large project with many namespaces and dependencies and it took about 20 seconds.
      - didibus 4y ago
        That seems pretty slow, I've never had it take more than 5 seconds, even on large enterprise backend services. Maybe your service was also initializing a lot of state/components on startup?
  - didibus 4y ago
    Sure it's a disadvantage, but the way you say it makes it sound like it results in a terribly slow development experience where you're constantly waiting for it to start. The truth is, the development experience actually gives you much faster feedback with almost no waiting time as compared to the majority of other languages. That means the impact of the slow startup isn't really felt. I think where slow startup is a bigger issue is actually for certain production use cases, like CLIs, or serverless settings. There it would be awesome if Clojure JVM also started in sub-millisecond, and we didn't have to change to Clojure interpreted like babashka, or Clojure GraalVM native compilation.

by synthc 4y ago

seancorfield 4y ago

It's not a workaround. It's how Clojure is designed, around its REPL, intended for interactive development at its core. Start a REPL, connect your editor, develop. You can start your apps in the REPL (from RCFs in your code -- Rich Comment Forms) and never type into the REPL. You can grow the application while it is running, you can run tests via the REPL from your editor. That interactive approach -- working on your application "live" essentially -- is what sets Clojure's REPL apart from other languages' "interactive consoles" (sometimes misleading also called REPLs :) And, yes, Babashbka is great for running CLI scripts. But that's a completely different use case to a long-running development process.

synthc 4y ago
I'm very familiar with the live editing aspect of Clojure, and I like it a lot actually. What I am saying is that Clojure's long startup time is still annoying if you want to restart, for example if you trashed your repl session or want to start with a clean slate. If Clojure would start fast enough it could also be used for CLI scripts and we would not need Babashka at all. All in all, I think Clojure is a great language, but the slow startup time is still a disadvantage.
- jeff303 4y ago
  Wait, how slow is it starting for you? On my 2012 Mac Mini, a clean clj 1.11 REPL (with no namespaces loaded) starts in under 5 seconds (using JDK 18).
  - synthc 4y ago
    No namespaces loaded is not a very good benchmark IMO, a real project will have lots of them. I've worked on a large project with many namespaces and dependencies and it took about 20 seconds.
    - didibus 4y ago
      That seems pretty slow, I've never had it take more than 5 seconds, even on large enterprise backend services. Maybe your service was also initializing a lot of state/components on startup?
- didibus 4y ago
  Sure it's a disadvantage, but the way you say it makes it sound like it results in a terribly slow development experience where you're constantly waiting for it to start. The truth is, the development experience actually gives you much faster feedback with almost no waiting time as compared to the majority of other languages. That means the impact of the slow startup isn't really felt. I think where slow startup is a bigger issue is actually for certain production use cases, like CLIs, or serverless settings. There it would be awesome if Clojure JVM also started in sub-millisecond, and we didn't have to change to Clojure interpreted like babashka, or Clojure GraalVM native compilation.