Evangelizing Clojure

Posted on 12 November 2011

I’m currently attending the second annual Clojure Conj, the premiere Clojure-specific conference. One of the themes that has been emerging is evangelizing Clojure: getting more people to use it, and convincing people to use Clojure who otherwise wouldn’t choose to use it.

This was in fact the central theme of Neal Ford’s talk “Neal’s Master Plan for Clojure Enterprise Mindshare Domination”, in which he put forward his ideas for how to get large organizations full of institutional inertia to adopt Clojure. Phil Bagwell also made reference to this in the introduction to his talk, in which he asked everyone using Clojure in their day job to put their hand up, then asked everyone who’s never deployed Clojure to production to put their hand up, then asked group 2 to talk to the nearest person in group 1 and ask them how they got to work in Clojure.

Clojure evangelism has also been a common theme of Q&A sessions after talks: a talk on ClojureScript will often be followed with a question such as “How do you fit this into an existing JavaScript project?”

There are a few key themes emerging:

Know your enemy

There’s a lot of competition amongst the new language communities, particularly between Scala, Clojure, and Groovy. This is absolutely fine and as it should be. Furthermore, if Scala is successful, this is in no way directly detrimental to Clojure.

Scala, Clojure and Groovy are in competition, but they are not enemies of each other. The real enemy is the status quo. It is the nasty feeling that people have when they say things like:

• “Taking on Clojure is a big risk – I want to be certain”
• “I think Clojure might be a better choice than Java, but because Java is an industry standard, I am more likely to get blamed if I choose Clojure and the project fails.”
• “If I choose Clojure, I don’t know I’ll be able to hire developers who know it”

Ultimately, these statements reflect a sentiment that staying with the same old technology is safer than trying to improve productivity by choosing a newer, but less well-known, technology.

If a client has switched from Java to Groovy, Scala, or JRuby, they have already rejected the status quo. Encouraging an environment in which people feel able to explore new technologies will make more people who are interested in Clojure overcome their fears and try it out. In other words, a rising tide raises all ships.

Be positive about the new possibilities, not negative about the status quo

By and large the feeling of the conference has been upbeat and positive, rather than tribal. That is why, when a couple of off-hand jokes about Ruby were made, people immediately called it out as nonconstructive.

Clojure and Scala in particular are languages which make many things possible which simply aren’t possible in other languages. This can lead to a feeling of superiority. Fight that feeling! Clojure is not going to gain mindshare by denigrating Ruby and Java; it is going to gain mindshare by promoting itself and solving problems effectively.

Furthermore, there are many problem domains where the existing tools are entirely appropriate — Rails is a fine framework, and although it has limitations, those limitations don’t manifest in most use cases. Even some of the clojure.core team use Rails for most of their work, and Clojure only for the difficult problems. Denigrating Rails builds walls, when we want to be building bridges.

Build grassroots through the back door

Many recent successes in language proliferation have been achieved simply by providing great tools in those languages. Even if someone doesn’t particularly want Ruby, they might well want Cucumber. If they don’t want Groovy, they might still want Gradle.

On my current project, we’re using node.js for a test stub, even though none of us is a particular JavaScript advocate. Node was just the best tool for the job, so we used it. But that’s caused a lot of us to look at JavaScript in a new way, and I’d say we’re all more likely to use JavaScript again in future as a result.

This is a great way to build up mindshare. I think one tool I’ve learned about at the conj which could fill this role is pulse from Heroku, described in Mark McGranaghan’s “Logs as Data” talk. Pulse is a tool for processing logs not as a stream of bytes but as a stream of events and rich data objects. Another is Cascalog, from Nathan Marz at Twitter, which is a high-level abstraction over Hadoop MapReduce, which creates a very nice internal DSL for modelling MapReduce computations as queries and predicates.

In summary

It’s been a really exciting conference for me, because Clojure is both a great language, and at a key point in its history. It has reached maturity, it is being used by a few people in production to solve interesting and difficult problems; but the next step is to evangelize Clojure, to get it used in earnest by more and more people.

Happy hacking!