Blog /  
Clojure Tools: Benefits, Pitfalls and Side Effects

Multitude of Clojure Tools: Huge Advantage or Big Problem?

June 6, 2021
8 min read

We've already talked about why developers choose Clojure and call it the most "elegant and enjoyable" language.

Also, we've gathered insights about the possible reasons for the unpopularity of Clojure. A sparse and undeveloped development toolset was listed among others.

So, how to improve the existing Clojure tool stack? What is happening right now in the community? When will we be satisfied by a fully-loaded Clojure machine and how its technical inspection will be handled? Let's think together!

In this post, we'll talk about the current state of the broad Clojure tooling ecosystem, contrast the approaches and tendencies we see today, including their strengths and weaknesses.

Clojure tooling landscape: tendencies and issues

Daniel Higginbotham, the author of "Clojure for the Brave and True", called learning a Clojure <medium>a journey through the Four Labyrinths:<medium>


<medium>Let's make a stop near the Forest of Tooling today.<medium> Clojure development basically requires:

  • IDE
  • REPL
  • dependency and build tool(s)

<medium>Instead of using frameworks, Clojure offers a number of powerful libraries that could be put together<medium>. It's a really handy approach, comparing, for example, with the JS development universe, where you typically have to learn a number of different tools and learn how they have to be used properly together.

Such a concept provides <medium>fast and quite easy tool development<medium>. It's such clay in the developer's hands to model everything he(she) wants. Some tools have become common "household names" amongst the devs, others are riding the bench, the third ones were proved unsuitable.

Clojure tools

It's easy to become overwhelmed by the sheer number of incomplete tools that can be included in a single project only. That is not the best factor for Clojure's 'ergonomic' and it spoils people's interaction with its ecosystem.


Clojure JVM

The main issue we are considering is <medium>a tendency of such a heuristic strategy for reaching immediate short-term goals, that is not guaranteed to be optimal and rational.<medium>

What are the risks of such an uncontrolled progression? And how to prevent Clojure tooling entropy?


Council of elders. Pandora's box or smart tool kit?

Pandoras box

Our goal is to become an enjoyable tipster for Clojure newcomers and provide interesting content for all Clojure-lovers. We want to discuss together how Clojure is used in real-world cases, what challenges we've faced and how can we deal with them.

Today we talk about the dilemma of Clojure tooling and the balance between well-established "canonical" Clojure tools and "one-off" things.

How to solve tooling problems like a boss Clojurist? We've asked Sean Corfield and Daniel Slutsky:

<medium>What do they think of tooling in Clojure: is it an advantage — allowing developers to quickly create tools according to the business needs — or would it make more sense to improve existing tools rather than create a new one?<medium>

Clojure titans have generously shared their deep thoughts on the subject.

Sean Corfield, veteran software architect, about the importance of using standard staff

I think we have all the tooling now that is needed and it's more about helping people select those tools. The pain points, for people who are just coming to Clojure, are around not knowing how to use the toolset that works with a CLI. There are also guides needed of what set of tools to use with it. I think this is the right place for encouraging people these days.

So on the tooling side, it's not a matter of producing new tooling, it's more <medium>a matter of curating a set of tools or making a good set for people.<medium>

There are probably things that could be done around that in terms of templates to produce simple, and I emphasize, <medium>SIMPLE<medium> projects that have all the necessary tools built into them. So maybe creating templates is a good area to look at.


I often ask: "We have a perfectly good solution here why have you now been creating a competing one?". And the answer is "Yes, it does something but it's not reaching what our team would have done if they would building it".

My position is I like to encourage people to use the standard simple tooling where possible. So I am the advocate of Clojure Spec instead of Schema and others. The main reason for that this is something that is designed by the Cognitect team and fits with the language.

I definitely try to encourage people by saying "<medium>Use Clojure CLI, Use Deps, Use Clojure Spec. Use simple mainstream libraries<medium>". That's why I still recommend Compojure. It is so much easier to teach people to use it.

If you are producing guided learning then try to stick as much as possible with Cognitect standard staff and with core standard libraries even if some of the others have been very well documented and are objectively better in some way. Because it is a good concept that people need. It's why for example I told people to avoid Mount and guided them to Component. I think that Component has better architecture and it is a simpler library to use.


Daniel Slutsky, co-organizer of Scicloj, about the main challenges and solutions

I'll comment from my own perspective, being involved in the Scicloj community, that is building Clojure tools and libraries for data science.

Clojure follows the Lisp tradition of dynamic, playful exploration, and makes it easy to invent new ways of expression. <medium>One result of this spirit is indeed a multitude of tools: several excellent IDEs, alongside tools for tasks such as building, testing & deploying projects, data visualization, literate programming, etc.<medium> Tools can be customized, and individuals are encouraged to create their own intimate way of interaction with code and data.

All that can be extremely fruitful, but also presents problems, as you hinted:


The Clojure community seems to develop its ways of coping with these challenges:


To conclude, I think the multitude of Clojure tools allows Clojurians to enjoy lots of useful combinations that can be tailored to their own need of playful exploration and creation. The community seems to be coping wisely with the challenges that come with this multitude, but there is still some way to go before the toolset becomes easy, simple, and friendly for newcomers.

Freshcode team about clojure took area





How to find clojure tools you need

Right clojure tool

Clojure Repositories

The answer is simple and well-known: seek and you will find.


P.S.: and don't hesitate to ask Clojure experts to help you. Clojure community is welcoming newcomers, it's such an unspoken rule, or better to say, a free will of its members.

Other links that may come in handy

Here are also some useful links that may come in handy when looking for <medium>Clojure tutorials and how-tos.<medium>


We hope you'll get inspired enough to start contributing to some tools (smartly combining strengths of conservatism and reformism :-)) !


(UN) final verdict

So, what is the future of Clojure development tools, jokingly called by Bozhidar Batsov "underappreciated workhorses that make our lives hacking with Clojure easier, more fun and more productive"?

Despite a challenging year overall, "2020 was another good year for Clojure and its ecosystem", according to the State of Clojure 2021 Survey. So we are not panicking about the tooling state in Clojure.

<medium>The language is still young and brave and it's going through specific development milestones<medium>. Anything that proves itself as an inefficient solution, will be discarded.


Building new tools in some cases really helps to create better products, in the other cases, it breeds 'one-off' things fading into oblivion over time.

To create great things let's adhere to the principles of:

  • well-organized tooling support
  • consistency
  • retaining the code clarity ("programs must be written for people to read, and only incidentally for machines to execute")

Please, feel free to write comments below the article if you want to share your point of view.

Freshcode provides Clojure development services matching your business goals. Do you want to know the benefits of Clojure software development or discuss ways how we can develop the Clojure community together? Please, just fill this contact form and one of our representatives will contact you within one business day.


Shall we discuss
your idea?
Upload failed. Max size for files is 10 MB.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
What happens after you fill this form?
We review your inquiry and respond within 24 hours
We hold a discovery call to discuss your needs
We map the delivery flow and manage the paperwork
You receive a tailored budget and timeline estimation