3 ms·

> 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 a

> 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.
- freshhawk 4y ago
  > I'm explaining to you why Clojure won't reach mass adoption I don't think you need to explain that, it's a conservative ecosystem for experienced devs, that was the target niche it was always aiming for. It's intentionally built to not reach that level of "mass adoption", mass-adopted, market dominating tools are one small subset of the set of useful software tools.
- capableweb 4y ago
  > I could offer you a long list of situations for which slow startup is a PITA This is exactly what I'm out after. In practice, slow startup doesn't hurt you, unless you use Clojure like you would use NodeJS or any other interpreted language, but that's not how the Clojure community uses Clojure, because it wasn't meant for that. Knowing how to use a tool for the job it was designed is not a "workaround", it's part of the documentation or knowing how to actually use it. If you don't want to adapt to your tooling then yeah, don't give that tool any of your time, because you'll just fight it. Trying to use something but not following what it recommends, is just a waste of everyone's time. Just like I wouldn't spend time trying to use Docker containers as VMs, you should not use Clojure if you constantly want to restart the process. Or sending high-quality videos via email. Or using VGA cables to send TCP packets. Or trying to use Rust to do meta/dynamic-programming. It wasn't made for that workflow, so why would you try to use it that way? I don't really care about what you or others adopt, the benefits of Clojure is not that everyone/a lot of people use it, but the benefits you get from adopting to the tooling it provides. So if people are not ready to give that a try, good riddance, I won't lose anything because of it.
synthc 4y ago
REPL driven development is great, but there are still tons of situations where you want a full recompile and restart. Slow compile and start time really slow down development. Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable.
- didibus 4y ago
  > Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable I think this tells me we differ greatly in our development approach. Because it seems you still practice a kind of traditional TDD. I'm not saying one is better, but I think this is either a personal preference of style, or maybe you haven't tried the Repl driven approach? For example, I almost never use REPL/refresh. Any amount of, delete state, reinitialize the whole app from scratch, be it by restarting the app like cargo does, or some tear-down/re-init like refresh does, is a very different approach to how I use the REPL, where I make many small changes that I hot-reload as I go, never really needing a full refresh. That allows me to maintain state and context as I code. Also, small applications are nice, but most real app will grow to be big applications, not sure how `cargo watch -X run` will keep up in that setting, it doesn't just become compile/start times at some point, it's also how long does it take to instantiate your SQL driver and establish a DB connection, start your web server, etc. REPL driven development allows all this to be initialized in the morning when you start your day, and just kept open till you clock out. So all development throughout the day you get instant hot-reloads of the functions you're changing, while maintaining all that state alive as you go.
  - synthc 4y ago
    I've worked with Clojure for years using the REPL driven approach and found I needed restarts quite often, for example when adding updating dependencies or other changes to the project file. REPL driven development is great, but sometime you want to make sure that you are not using some function that was only defined in the REPL session but not in the source code. Also the REPL session sometime gets in a bad state when printing big outputs, blocking forever with some concurrency stuff or other mistakes.

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.

freshhawk 4y ago
> I'm explaining to you why Clojure won't reach mass adoption I don't think you need to explain that, it's a conservative ecosystem for experienced devs, that was the target niche it was always aiming for. It's intentionally built to not reach that level of "mass adoption", mass-adopted, market dominating tools are one small subset of the set of useful software tools.
capableweb 4y ago
> I could offer you a long list of situations for which slow startup is a PITA This is exactly what I'm out after. In practice, slow startup doesn't hurt you, unless you use Clojure like you would use NodeJS or any other interpreted language, but that's not how the Clojure community uses Clojure, because it wasn't meant for that. Knowing how to use a tool for the job it was designed is not a "workaround", it's part of the documentation or knowing how to actually use it. If you don't want to adapt to your tooling then yeah, don't give that tool any of your time, because you'll just fight it. Trying to use something but not following what it recommends, is just a waste of everyone's time. Just like I wouldn't spend time trying to use Docker containers as VMs, you should not use Clojure if you constantly want to restart the process. Or sending high-quality videos via email. Or using VGA cables to send TCP packets. Or trying to use Rust to do meta/dynamic-programming. It wasn't made for that workflow, so why would you try to use it that way? I don't really care about what you or others adopt, the benefits of Clojure is not that everyone/a lot of people use it, but the benefits you get from adopting to the tooling it provides. So if people are not ready to give that a try, good riddance, I won't lose anything because of it.

synthc 4y ago

REPL driven development is great, but there are still tons of situations where you want a full recompile and restart. Slow compile and start time really slow down development. Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable.

didibus 4y ago
> Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable I think this tells me we differ greatly in our development approach. Because it seems you still practice a kind of traditional TDD. I'm not saying one is better, but I think this is either a personal preference of style, or maybe you haven't tried the Repl driven approach? For example, I almost never use REPL/refresh. Any amount of, delete state, reinitialize the whole app from scratch, be it by restarting the app like cargo does, or some tear-down/re-init like refresh does, is a very different approach to how I use the REPL, where I make many small changes that I hot-reload as I go, never really needing a full refresh. That allows me to maintain state and context as I code. Also, small applications are nice, but most real app will grow to be big applications, not sure how `cargo watch -X run` will keep up in that setting, it doesn't just become compile/start times at some point, it's also how long does it take to instantiate your SQL driver and establish a DB connection, start your web server, etc. REPL driven development allows all this to be initialized in the morning when you start your day, and just kept open till you clock out. So all development throughout the day you get instant hot-reloads of the functions you're changing, while maintaining all that state alive as you go.
- synthc 4y ago
  I've worked with Clojure for years using the REPL driven approach and found I needed restarts quite often, for example when adding updating dependencies or other changes to the project file. REPL driven development is great, but sometime you want to make sure that you are not using some function that was only defined in the REPL session but not in the source code. Also the REPL session sometime gets in a bad state when printing big outputs, blocking forever with some concurrency stuff or other mistakes.