Data and commentary on the results

The survey ran from the 22nd of February to the 28th of March. Most questions allowed more than one answer, so percentages will not add up to 100. At the time of this writing, (28 March) there were just over 500 responses.

Last year's survey is still up.

It may be interesting to compare some of these results with Chas Emerick's State of Clojure survey from last summer.

You can see the source for this survey on Github or get the raw results for your own analysis.

Total responses: 513

How long have you been using Clojure?

Weeks
26 (5%)
Months
97 (18%)
1 year
124 (24%)
2 years
112 (21%)
3+ years
145 (28%)

Last year's "2 years" bracket seems to have shifted into the "3+ years" bracket, which should come as no surprise given that a year has passed. Growth seems fairly strong—a quarter of respondents weren't using Leiningen when last year's survey happened.

For what do you use Leiningen? (pick as many as apply)

Open source
398 (77%)
Proprietary projects
324 (63%)
Libraries
279 (54%)
Web sites
290 (56%)
Deployment
130 (25%)
Backend code
258 (50%)
GUI clients
73 (14%)
Command-line applications
197 (38%)

This is basically the same as last year. Some small growth in GUI and drop in CLI. This question probably won't return next year.

Do you deploy jars with Leiningen?

to Clojars
192 (37%)
to other public repositories
16 (3%)
to private repositories
180 (35%)

Clojars now has more people publishing to it than internal private repositories, though private repos remain surprisingly common. Use of other public repositories has dropped to nearly nothing.

When did you start using Leiningen?

I don't remember
25 (4%)
0.x (Nov 2009)
36 (7%)
1.x (Dec 2009 - Mar 2012)
323 (62%)
2.0.0-previewN (Mar 2012 - Jan 2013)
87 (16%)
2.x (Jan 2013 - present)
32 (6%)

This reflects what we've seen from the first question; the majority are old-timers from the days of 1.x. However, the survey was announced a bit over a month after the release of 2.0.0, so there's a decent chunk of users starting on the fairly recent new version.

What operating systems do you use Leiningen on?

GNU/Linux
403 (78%)
Mac OS X
320 (62%)
Windows
96 (18%)
Cygwin or other Windows GNU
35 (6%)
Solaris
6 (1%)
BSD
6 (1%)
other
2 (0%)

It's difficult to compare this with last year's results since last year was a lot more granular. Nearly everyone (80%) uses Leiningen on Linux-based systems, while a majority also use it on Macs. Windows is up to 19%, which is a modest growth of 3%. Recently (since the survey opened) Leiningen gained the ability to do self-install on Windows without extra third-party downloads, so that may boost this number in the future.

What package managers do you use?

apt
350 (68%)
yum
76 (14%)
nix
6 (1%)
portage
19 (3%)
pacman
52 (10%)
BSD ports
9 (1%)
homebrew
253 (49%)
macports
47 (9%)
fink
3 (0%)

Since last year apt-get has cemented its lead with a further 7% growth to 69%. Homebrew has jumped from 32% to 50%, with MacPorts dropping to the single digits. And this year I'm not the only one on nix, which I take as a small encouraging sign of things to come.

How do you install Leiningen?

Downloading bin/lein
449 (87%)
Package manager
77 (15%)
Git
59 (11%)

The manual install remains far and away the most popular way to install. This is probably due to the fact that the Debian packages for Leiningen are taking a while due to the large number of prerequisites that need packaging. Volunteers very much welcome for that. I'm assuming everyone running from git is a contributor or intending to become one.

What's the oldest JVM version you use regularly? (java -version)

1.6.0_18 or older
26 (5%)
1.6.0 newer
270 (52%)
1.7.0
191 (37%)
1.8.0
7 (1%)

This is a new question, motivated partly by wondering how common JVMs which predate tiered compilation tweaks are. Uptake of 1.7 is happening fairly rapidly, and the vast majority of 1.6 users have the improved tiered compiler. This is great news since it gives Leiningen a pretty serious speed boost. Users on older JVMs will have to disable it manually by setting LEIN_JVM_OPTS.

Which Leiningen features do you use?

custom profiles
253 (49%)
aliases
79 (15%)
checkout dependencies
271 (52%)
editor/IDE integration
232 (45%)
native dependencies
111 (21%)
auto-cleaning of transitively-compiled .class files
83 (16%)
pom task (other than for Clojars)
64 (12%)
CLI repl
313 (61%)
test selectors
101 (19%)
trampoline task
158 (30%)

Profiles are a new feature in Leinigen 2.x, and they seem to be very popular. Surprisingly the CLI repl remains more popular than editor integration; perhaps due to it being fairly foolproof to set up. I suspect aliases would be more widely used if they were more prominently documented. Native dependencies have 20%, which is quite high for a feature that's virtually undocumented and not used by hardly any of the main contributors.

Do you use Leiningen for any mixed-language projects?

Only Clojure
295 (57%)
Clojure with Clojurescript
207 (40%)
Only Clojurescript
38 (7%)
Clojure with Java
206 (40%)
Clojure with another JVM language
23 (4%)
Plain Java
17 (3%)
Another JVM language alone
1 (0%)

Obviously pure-clojure projects are the most popular, but surprisingly mixed Java/Clojure projects are used by a large minority; up from 20% to 40%. My impression was that including Java source only happened with legacy projects and that this would become less common as time went on, but clearly that isn't the case. Clojurescript is nearly as widely used as Java, which is surprising given that only 57% of users are working on web applications to begin with. There are even a few brave souls using Leiningen for pure-java projects and someone using it for a Scala or Groovy project.

Favourite plugins?

  1. ring (61)
  2. cljsbuild (49)
  3. midje (31)
  4. kibit (28)
  5. pedantic (23)
  6. marginalia (23)
  7. outdated (18)
  8. pprint (12)
  9. immutant (12)
  10. ritz (11)
  11. swank (11)
  12. clojars (10)

I've omitted plugins with results in the single digits, so these are the big rollers. The dominance of lein-ring and cljsbuild come as no surprise given the results above. It's great to see lein-pedantic scoring so high since it's quite the newcomer. ritz is a rising star addressing the long-standing complaints around debuggers. swank-clojure holds on despite active development having stopped, which is fine; it still works as-is.

Favourite templates?

Only six templates got multiple votes: the default template tied with compojure (9), app (6), luminus (3), speclj (2) and heroku (2). Seems like template needs are fairly diverse and possibly aren't particularly memorable when it comes to survey responses.

What annoys you about Leiningen?

startup time
285 (55%)
difficulty finding dependencies
52 (10%)
lack of plugins
19 (3%)
support for native code
25 (4%)
unmanaged jars
82 (15%)
leiningen's own end-user docs
56 (10%)
docs on extending Leiningen or writing plugins
73 (14%)
other (see comment box below)
31 (6%)

Startup time has always been the number one complaint about Leiningen, and the results reflect that. There are a number of tricks which can speed up boot, but most of them remain fairly experimental. Hopefully we see some progress on those fronts in the upcoming months. I'm glad to see that people unsatisfied with Leiningen's end-user documentation remain a small minority (11%) though unfortunately they neglected to be specific about what it was they found lacking in the comments. For the lack of attention that's gone into native dependencies, it's not a major pain point for many either, though when it is a problem I suspect it's a big one. Only 10% report having a hard time finding dependencies, which has been a problem in the past. Documentation on internals and writing plugins is weaker; this is a place where people are forced to fall back to IRC. Plugin coverage seems really strong.

Do you have a GPG key?

Yes, and I've gotten it signed by others
34 (6%)
Yes, and I have used it
129 (25%)
I have one, but I've never used it
93 (18%)
I've been meaning to get one
62 (12%)
No
176 (34%)

The answers here were very encouraging; over half of respondents had a GPG key, and a third of those that didn't mentioned wanting to get one. I suspect the recent attack on rubygems.org may have helped raise awareness here.

Do you have custom tasks you haven't published as a plugin?

Yes
83 (16%)
No
401 (78%)

This came up repeatedly under the free-form comments section too: I have a suspicion that most people who think they need to write a Leiningen plugin would actually be perfectly happy with an alias. Leiningen 2 introduced partially-applied aliases, which means you can create an alias to the run task which has some arguments (-m my.namespace typically) partially applied to the task function. As long as you don't need access to the project map itself, an in-project namespace can do the trick nearly every time. This is a topic that deserves more in-depth explanation, so I hope to write something up soon.

Did you know if you have a single patch accepted you can ask for commit rights and a sticker?

Yes
109 (21%)
No
381 (74%)

This is up from 13% last year; yay progress.

Other Comments Summarized

Lots of just generally positive comments here, so thanks everyone! You're the best. People love the logo, which of course I can't take credit for.

A few people mentioned the complexity of the internals, and I completely agree that there are a few places in which things have gotten out of hand. Nobody feels this more keenly than I do. The logic for merging profiles and applying middleware in particular is treacherously subtle. Luckily it's fairly isolated, so unless you're specifically touching profile logic you can ignore it, but profiles are a big part of what makes Leiningen flexible. In the back of my head I'm already planning what can be done for Leiningen 3, and rewriting profile logic is on the top of the list.

There were some complaints about Windows support, but recent patches (some mentioned above) from David Powell seem to go a fair ways towards addressing these. In particular the installation situation is a lot nicer in 2.1.

I'm never quite sure what I need to do to successfully publish or use a SNAPSHOT release. I don't know how to force Leiningen to download a new version of a SNAPSHOT.

You can do this with lein -U deps, which is an alias for lein with-profiles update deps, but this should probably be in the FAQ. There are a few features like this tucked away that are not very discoverable; it's difficult to know how to expose them.

In desperate need of a proper release plugin.

I'd punted on the automation of bumping version numbers since for a long time there was no way to read Clojure code in a way that preserved comments for round-tripping, but now that exists, so no more excuses! This should probably begin life as a third-party plugin and get merged to Leiningen once it's polished and matured though.

There were some complaints about the difficulty of getting started with GPG, but Leiningen 2.1 now ships with a GPG guide which should help a lot on that front.

One thing that would be of interest to me, is a blog post or series on leiningen's internal design (if one doesn't already exist).

Daniel Higginbotham has started a series on how Leiningen works starting with a post on lein run and a follow-up on trampoline that has done a great job covering tricky topics so far.

Lein deps :tree should highlight conflicting dependencies.

This can be done currently by the lein-pedantic plugin, but there's no reason it couldn't be included in Leiningen proper as it's handy for debugging.

Other things that annoy me about leiningen is the lack of phases. Having to rerun prep tasks before each task can be slow [...] compiling with different profiles.

There's an open issue for this; I don't think Maven-style phases are the right solution here, but I agree that changing profiles shouldn't force you to re-compile everything. I think by isolating :target-path on a per-profile basis this could be avoided. I hope to include this in version 2.2.

Don't know where to find all the plugins available and what functions they have.

While it's not 100% complete, plugin authors are encouraged to add their plugins to the plugins page of the wiki, so that's a great place to start.

See all free-form comments.