Comment by iLemming | Hacker News Reader

Comment by iLemming | Hacker News Reader

Parent Full thread

> Clojure has massive amounts of ecosystem and toolchain pain

Oh come on. Why do programmers like to exaggerate things in plain English? Maybe because naming variables using words like "massive", "colossal", or "monumental" won't fly in a programming language?

There's no "massive amount of toolchain pain". Did you use Clojure last time in 2012 or something?

You can literally just install Clojure and start writing Clojure programs in your shell.

Well, if you want something personalized or project-specific, then of course you'd have to learn some stuff, that's not gonna change for any general-purpose programming language. And I don't know how you can get more general purpose than Clojure - it can run on JVM; on JavaScript platform; on .NET CLR; in Flutter; can do R and Python interop, you can write bash scripts using Babashka and nbb.

The days when you needed to learn Emacs to use Clojure are well in the past. Today you can write Clojure in Vim, VSCode, IntelliJ, Atom, Sublime, Nightcode, Emacs and even Eclipse.

There's been a fair amount of churn in the ecosystem, even if the language itself has been very stable. Leiningen was ubiquitous 5-6 years ago, but if you switched to using deps for dependency management you lost the ability to run tests or build uberjars and had to manually re-create these on a per-project basis. Now there's tools.build, but that also requires you to manually write essentially the same tasks for basic functionality in each project. Leiningen and tools.deps also seem to resolve depedencies differently, so you can run into issues simply by migrating from one to the other.

That's not "massive amounts of toolchain pain", this happens in every general-purpose language, I'd say: that's "business as usual".

Like in Javascript, for example, any lib composed with CRA (Create React App) is painfully difficult to re-use in non-CRA apps. You constantly run into dependency resolution pain with Haskell; Python has toolchain resolution problems; .Net has its own challenges. Well, at least .Net folks don't have to run three different, incompatible versions of Visual Studio anymore to compile a single project. I do remember those days.

If I had to run multiple versions of Clojure, Leiningen, or CIDER on a single machine to compile different projects, or if Clojure folks had to invent something like pyenv, yeah, I'd agree that there is a problem.

You just can't make everyone happy. People either complain that "Clojure is dying" because some lib hasn't been updated since March, or "Clojure has too much churn" because Cognitect rolled out a new lib.

Clojure earned the fame of being very stable because you can pick any five-six years old project and it still would compile. Now you're complaining that you've decided to switch to a different build tool and saying it's painful?

Do you know what's painful? Having to migrate from Angular to React and to keep them both in the same .js project during the transition phase. Clojure has nothing of that sort. So many times we slowly moved from one thing to another with virtually zero downtime.

I can compare the frustration you seem to describe with my own experience building thing in different languages. Clojure by far is the least frustrating in that regard.

Reply on news.ycombinator.com