5 ms·

Clojure is a wonderful language, but not so wonderful that I can tolerate its slow startup and compile times. I think lots of developers think the same way. Imo

Clojure is a wonderful language, but not so wonderful that I can tolerate its slow startup and compile times. I think lots of developers think the same way. Imo any language nit facilitating fast startup and compile is stillborn. Imo the same goes for any language requiring you to setup a "project" or something to get started.

didibus 4y ago
Slow compile times? You don't even need to compile Clojure to run it. It only has slow start time, but since you work at an always connected REPL, it's pretty much instantanuous throughout your entire work day. Start it in the morning (takes a few seconds at most), and then it's instant feedback until you clock out. And for slow start time for deployment use cases that need fast start time, like CLIs, scripts, serverless, you can either use babashka, Clojurescript, or compile Clojure to native using GraalVM.
capableweb 4y ago
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).
        4y ago
- 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.
yogthos 4y ago
Babashka is an excellent Clojure runtime with fast startup that I use for all my scripting needs nowadays. Best part is that you can develop with it interactively via nREPL just like regular Clojure. You just run bb --nrepl-server and connect your editor to it. https://babashka.org/ https://babashka.org/

didibus 4y ago

Slow compile times? You don't even need to compile Clojure to run it. It only has slow start time, but since you work at an always connected REPL, it's pretty much instantanuous throughout your entire work day. Start it in the morning (takes a few seconds at most), and then it's instant feedback until you clock out. And for slow start time for deployment use cases that need fast start time, like CLIs, scripts, serverless, you can either use babashka, Clojurescript, or compile Clojure to native using GraalVM.

capableweb 4y ago

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).
        4y ago
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.

yogthos 4y ago

Babashka is an excellent Clojure runtime with fast startup that I use for all my scripting needs nowadays. Best part is that you can develop with it interactively via nREPL just like regular Clojure. You just run bb --nrepl-server and connect your editor to it. https://babashka.org/ https://babashka.org/