5 ms·

Yeah, Clojure is not great for CLIs, but pretty much every other use case it excels at. For CLIs, there is always Babashka (https://babashka.org/ https://babash

Yeah, Clojure is not great for CLIs, but pretty much every other use case it excels at. For CLIs, there is always Babashka (https://babashka.org/ https://babashka.org/) which works good enough. For local development, you usually just compile+eval one function at a time as you change them, and those happens under 1ms, not enough to even notice (unless you develop with a remote REPL, but then network is to blame) For server usage, you usually compile once in CI and put the resulting binary/JAR on the server. A few seconds for startup matters less in those cases. The drama of slow Clojure startup is wildly overblown, because basically for no other use case than writing CLIs, does the startup time matter so much it becomes a problem.

seancorfield 4y ago
Indeed, yes. For development, if you're finding "slow startup" to be a problem, you're just doing it wrong: start a REPL and leave it running -- mine run for days (or even weeks).
- 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.
bjourne 4y ago
No, you are missing the point. Slow startup and long compiles is a hindrance to all kinds of development. You can ask developers to adapt and use a long-running repl, but they won't. Complain all you want about drama and how stupid people are, they still won't choose Clojure.
- didibus 4y ago
  > You can ask developers to adapt and use a long-running repl, but they won't I mean, that's a you problem. My team is well adapted. Does your team also code in notepad exclusively and chooses to not use an editor with IDE features? Cause I feel that's your argument, that people won't bother using any tooling when developing in a language out of laziness to learn to use tooling? Even if the REPL started in sub-milliseconds, I'd still be connected to a long-session most of the time. Why restart it constantly? There's no point, you lose your state, you lose the context you were in, it take me out of my productivity zone.
- capableweb 4y ago
  > Slow startup and long compiles is a hindrance to all kinds of development What kind of development do you do where you have to recompile the entire program and restart the process on every change? No Clojure developer develops like that, just like no Smalltalk developer would reload the entire environment for every change, or no Rust developer would recompile the entire dependency tree for every change. In Clojure land, you just compile/eval what changes without restarting the process, that's like 50% of the reason you'd chose to go with Clojure in the first place.
  - bjourne 4y ago
    I'm explaining to you why Clojure won't reach mass adoption. I could offer you a long list of situations for which slow startup is a PITA and you would rebut my points by offering workarounds and I would rebut yours by showing why the workarounds are ineffective, and so on, but it would be waste of time. Users (me included) don't want to have to adapt to their tools. Tools that require users to adapt won't be popular. Perhaps you don't get it, but this is reality.
thisiswrongggg 4y ago
I think it's more of a problem in combination with serverless cloud computing.

seancorfield 4y ago

Indeed, yes. For development, if you're finding "slow startup" to be a problem, you're just doing it wrong: start a REPL and leave it running -- mine run for days (or even weeks).

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.

bjourne 4y ago

No, you are missing the point. Slow startup and long compiles is a hindrance to all kinds of development. You can ask developers to adapt and use a long-running repl, but they won't. Complain all you want about drama and how stupid people are, they still won't choose Clojure.

didibus 4y ago
> You can ask developers to adapt and use a long-running repl, but they won't I mean, that's a you problem. My team is well adapted. Does your team also code in notepad exclusively and chooses to not use an editor with IDE features? Cause I feel that's your argument, that people won't bother using any tooling when developing in a language out of laziness to learn to use tooling? Even if the REPL started in sub-milliseconds, I'd still be connected to a long-session most of the time. Why restart it constantly? There's no point, you lose your state, you lose the context you were in, it take me out of my productivity zone.
capableweb 4y ago
> Slow startup and long compiles is a hindrance to all kinds of development What kind of development do you do where you have to recompile the entire program and restart the process on every change? No Clojure developer develops like that, just like no Smalltalk developer would reload the entire environment for every change, or no Rust developer would recompile the entire dependency tree for every change. In Clojure land, you just compile/eval what changes without restarting the process, that's like 50% of the reason you'd chose to go with Clojure in the first place.
- bjourne 4y ago
  I'm explaining to you why Clojure won't reach mass adoption. I could offer you a long list of situations for which slow startup is a PITA and you would rebut my points by offering workarounds and I would rebut yours by showing why the workarounds are ineffective, and so on, but it would be waste of time. Users (me included) don't want to have to adapt to their tools. Tools that require users to adapt won't be popular. Perhaps you don't get it, but this is reality.

thisiswrongggg 4y ago

I think it's more of a problem in combination with serverless cloud computing.