Live data from Hacker News

Ask HN: Is Clojure Dead?

news.ycombinator.com

71–80 of 145 posts

Re: Ask HN: Is Clojure Dead?

#71
post #28
post #14

One benefit of learning functional languages, whether Haskell or Clojure, is that it makes you a better developer in other, non-functional, languages.

can you clarify "how" it makes one a better developer? When I think of how the java streams API is used, it generates lots of garbage (i.e. lots of intermediary allocs), doesn't always make things clearer.. i'm genuinely curious (and in fact i like the streams API, it's just often misused by collecting at the wrong step..).

It depends your area of work.

If you're working on graphic engines, quants, system programming, you won't really be using a GC language anyways. There, being a better programmer is a lot about low level in the small design details.

If you're instead working on enterprise or consumer applications, backend processing, big data, information systems, saas, etc. There, you'll find Clojure makes you a better programmer, because it teaches a lot about in the medium to large design skills for growing such systems, where high/medium level decisions matters more and micro-opromizations a lot less.

Things that I've learned from Clojure are:

    * Better grasp of OOP and polymorphism
    * Better grasp of recursion and memoization in general
    * Better code structure for independent, modular, and reusable designs
    * Better isolation of external effects and internal business logic
    * Better, safer and more clear data manipulation techniques
    * Better domain modeling and data modeling 
    * Better handling of data at the boundaries of my application
    * Logic programming
    * Better understanding of mutation/immutable trade-offs
    * Better balance between spaghetti code and lasagna code
    * Monads and other functional patterns
    * Better use of higher order functions that benefit code understanding, extensibility and reuse
    * Better understanding of language design, code parsing and generation
    * Better understanding of numbers in general and numeric tower details
    * Better understanding of dependency injection and stateful components
    * Better understanding of parallel computing and various lock and lock-free designs
    * Better understanding of asynchronous and concurent computing, use of events, queues, CSP, future/promise, structured concurency, etc.
    * The awesomeness of structural edits, homoiconicity, and Lisp in general
    * The awesomeness of interactive live programming
    * Emacs

Re: Ask HN: Is Clojure Dead?

#72
post #31
post #30

Earlier quoted context omitted.

Do you have examples of the dev experience degrading? My experiences is that the tools and libraries only continue to mature (as does the Clojure language itself). Do you just mean that things are improving less quickly than they are for, e.g., Typescript?

I mean compared to a few years ago. I tried setting up a new project after 1 or 2 years away from the ecosystem, and struggled a lot : all existing templates to set up new projects (esp. with CLJ/CLJS combined) had bitrotten and were not usable out of the box ; emacs integration no longer working out of the box, etc. I think it's a "death by a 1000 cuts"/"broken windows" that is may be happening when the ecosystem la…

In my experience, the old tools are generally rock solid and are still viable—deps.edn is where a lot of the momentum is going, but Leiningen still works as well as ever. I haven't actually tried to create a new project from an old template recently, but projects I created with old template still run fine.

The big exception is ClojureScript. I haven't personally noticed bitrot as much as ClojureScript being generally flaky. I think the situation is improving, though, and the unreliability is mostly in compilation and hot-reloading, not at runtime.

I think Clojure could use more funding to improve tooling, but I do think we have made strides with the funding we have.

Re: Ask HN: Is Clojure Dead?

#73
post #8

I am learning Clojure right now and I can relate to the feeling of not wanting to put time and effort into it if there is no marketable value in return. One thing that is motivating me is I read an article about how niche languages can be lucrative. (I want to say that article was here on HN but too lazy right now to search for it). The other thing that is motivating me is that this type of programming and thinking i…

> read an article about how niche languages can be lucrative. (I want to say that article was here on HN but too lazy right now to search for it)

I'm not having any luck finding it -- if you find yourself more eager (heh) I'd love to get a link.

Re: Ask HN: Is Clojure Dead?

#74

Clojure is definitely not dead. There are active Clojure user groups in most countries (even in my little region) and i still (or even more than ever) stumble uppon cool and exiting projects and libs (e.g. https://github.com/borkdude . It's just incredible what a surplus value this dude alone provides to the ecosystem) Clojure may not have the biggest audience but like others said, it generally focuses more on stabil…

> It's just incredible what a surplus value this dude alone provides to the ecosystem)

Seconded; it's pretty jaw-dropping!

> The tight feedback loop you have while molding a running program in your editor and the constant dopamine drip feed it causes are just too addictive.

Well-said -- I've been needing to write some Python recently, and it's only redoubled my preference for Clojure; the Python shell is a poor substitute at best for the Clojure REPL :(

Re: Ask HN: Is Clojure Dead?

#75
post #67

Earlier quoted context omitted.

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.

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

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.

Re: Ask HN: Is Clojure Dead?

#77

For the US, Google Trends reveals that Clojure's heyday came in 2013, and it has been on a decline since[0]. It never really reached the interest level of Scala, and of course recently Rust is consuming all the air in the room. Except, just for kicks I add Golang, and it turns out that all of the above are marginal compared to Go[1]. HN posts are very different from general interest, but yeah, I'd go with "Clojure ha…

Clojure never had a "shot to become a popular general-purpose language". That was never its goal. Popularity is not a useful measure of whether something is actually good technology. Clojure is designed to solve hard problems, for people who want something objectively "better" than mainstream tools. That's why it tends to attract more senior developers -- people who've felt the pain of other languages and want someth…

[deleted]

Re: Ask HN: Is Clojure Dead?

#78
post #75

Earlier quoted context omitted.

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

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…

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

Re: Ask HN: Is Clojure Dead?

#79
post #67

Earlier quoted context omitted.

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.

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

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.

Re: Ask HN: Is Clojure Dead?

#80

Earlier quoted context omitted.

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/ ) 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 usu…

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).

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.

Post reply on HN