Hacker News Reader

Comment by billfruit | Hacker News Reader

Clojure has massive amounts of ecosystem and toolchain pain, even though it is a cool language. Most common dev environment for it is a complex emacs tool chain. If you are seeking the simple joys of programming, Clojure is unlikely to be what you want.

View on HN

This was the path i was sign posted to take and I felt like onboarding was fun:

    1. I needed to install clojure https://clojure.org/guides/install_clojure
    2. I needed an editor, i wanted to use VSCode so the Calva plugin was what i needed https://calva.io/paredit/ 
    3. I needed to learn how to edit Clojure, i tried going beyond this point without learning paredit and it slowed me down so i came back and invested an evening - in vs code do ctrl+shift+p then choose the calva getting started repl
    4. You need build tooling and it seemed the choices were lein (easy user experience but not “blessed” future direction? - not sure about what i’m saying here  but it’s the understanding i formed). Tools.deps is the blessed approach but designed to customise the heck out of it - problematic for a beginner like me! Thankfully you can park the customisation for later and just get started with a well laid out starter https://github.com/practicalli/clojure-deps-edn - there’s even a video walks you through its features, all the inspectors and visualisers are nice to know about but not needed yet on a beginner journey

At this point I was free to do whatever. In my case so far that’s meant a toy project in reframe (loved it), another in luminus (also loved it), then i went off on learning more of the language since i felt lack of familiarity was most of my challenges with my luminus project.

Clojure is one of my fun languages. I laughed along to a TSoding video where the chap was quite openly dismissive of clojure as he went along but everything he tried just worked and fell into place like dominos. It just made me chuckle. https://m.youtube.com/watch?v=7fylNa2wZaU

I have Bob Nystrom’s interpreters book and i intend to use clojure as i go through that. We’ll see how successful i am…

Thanks for preventing the frustration there. I’ll try to survey the landscape I guess.

I also haven’t taken on rust. But I’m really wanting to play with a smaller language that has enough to do something practical with. The C replacement languages like Nim are cool, but not appealing for me yet.

It’s been a while since I’ve used a LISP. I’ve always gotten things out of those forays that changed the way I looked at making software.

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

Clojure with VSCode (with the Calva extension) is a breeze.

Reply on news.ycombinator.com