
State of Clojure Survey 2019 Analysis - kgwxd
https://danielcompton.net/2019/02/06/clojure-survey-2019
======
jakebasile
I've said it before and I'll say it again, the industry can rip Clojure from
my cold, dead hands. It's unfortunate that people in this thread seem to down
on the language, but the only possible way I would stop using it is if I
literally cannot earn income with it. It is by far the most pleasant language
I've ever used, I feel at home writing it, and it improves the quality of my
work.

~~~
alexbanks
I am not disagreeing nor challenging you; I'm happy you like it and I think
you should keep using it since you enjoy it so much. My question is: Wouldn't
the same be said by most programmers with a high degree of proficiency with a
language? What sets Clojure apart from Haskell or Scala or Elixir or Erlang?
Do you have a high degree of proficiency with something else?

Clojure is the language that I have always wanted to learn, but the benefits
never seemed very apparent. I'm hoping your response will make them clear.

~~~
jakebasile
Some experienced devs might say the same thing if they've also found a
language that just clicks with them as I have.

Clojure is a locus of things I really, really like and I have no reason to
change despite the recent FUD around it. Namely: Lispiness, dynamic typing,
functional programing, immutability, lean pragmatic design, and it runs on the
JVM. I haven't seen anything that compares to it in these regards that also
has the community support that Clojure has (great projects like Leiningen,
Lacinia, and so on).

I've tried Haskell but felt I was fighting the compiler due to the static
typing (I hate static typing). It also felt like it was designed for eggheads
and not people like me just doing a job. Scala feels like it doesn't know what
it wants to be when it grows up. Elixir and Erlang are neat but I haven't had
a chance to really try them out, but Elixir's choice to emulate Ruby-like
syntax is unfortunate.

That said, I do have a high degree of proficiency with Python, which shares
dynamic typing and kinda-functional programming with Clojure. Python was my
language of choice for years before I finally gave Clojure a try, and I
haven't really looked back. The poor handling of the Python 3 switch really
soured me to Python.

I also did a good chunk of Go, but the static typing and syntax weirdness just
killed it for me. Amusingly, Go seems to have a similar "ivory tower" approach
to language design to Clojure - which indicates that type of management isn't
really a problem for me.

~~~
Gene_Parmesan
My question for you would be, why Clojure over, say, Racket? Is it just the
JVM?

I personally prefer Racket because of the ease with which you can use it to
hack on itself. Macros are no stranger to LISPs, but Racket goes beyond by
having the entire system around it built to accommodate language design and
modification.

Want to use dynamic typing? Just use #lang racket. Want to use static type
checking? Use #lang typed/racket. Reactive programming is there with #lang
frtime. And that's before we even consider things like Scribble.

As an aside, I totally agree with you on Elixir. Erlang is wonderful for what
it's built for. Elixir's choice to use Ruby syntax, however, ruins Elixir for
me -- and it's not because I hate Ruby. I actually like Ruby a fair deal.
Instead, it's because using Ruby syntax makes it more difficult (for me) to
truly and fully _think_ in the paradigm. Erlang/Elixir are _nothing_ like
Ruby. Making the syntax Ruby-like just obfuscates what's actually going on in
the system. (I find similar issues whenever I try to program using imperative
chunks in, say, F# or Scala.) Just my two cents.

~~~
jakebasile
The answer is just that I haven't gotten around to trying Racket. I've eyed it
now and then but I've never done anything serious with it. It does seem to be
the closest match for me barring Clojure.

That said, the JVM is a huge part of why I like Clojure. Because of the
mountains of corporate code written in Java there is an insane amount of
pretty high quality (if extremely object oriented) code available for it. I
can find a library for basically any third party tool I'd want to use and if
someone hasn't written a Clojure wrapper for it yet I can whip one up pretty
quickly most of the time.

~~~
euccastro
And sometimes I can do fine with no wrapper at all. Not only there's a lot of
JVM code available, but interfacing with it is pretty quick, straightforward
and smooth compared to wrapping C (or, god forbid, C++) from any Scheme I
tried. I found that's very important. You can have lots of code theoretically
available for wrapping, but there's more of an impedance mismatch between C
and Scheme (think continuations/TCO, garbage collection, type conversion, and
the fact that some tools in Racket/Scheme ecosystems will be blind to what
happens in C land) so in practice it's a lot more work.

------
moomin
Okay, here's my take on the implicit narrative here: Clojure is done. It will
continue to improve, people will continue to use it and build cool things with
it, but maintainers are burnt out, mostly because there aren't enough of them
and partly because of the passive-aggressive relationship Cognitect has with
the community.

There's a whole bunch of languages with small dedicated communities doing
interesting stuff. D and Julia occur to me off the top of my head. It's not
"failure" that Clojure doesn't really challenge Kotlin or Scala for mindshare.
It's nonetheless disappointing for people like me who used to be really
excited by Clojure's potential.

Could it have been different? I don't know. The powers that be could
definitely have been more committed to growing the base, but it never seems to
have interested them. Would it have made a difference? I honestly don't know.

~~~
hota_mazi
The trend of programming languages is to move toward static typing. Not as an
afterthought, with gradual typing or retrofitted years later into an unwilling
compiler, but languages designed from day one with static typing, parametric
polymorphism, and type inference.

Clojure's life time was limited from day one because it's simply going against
the trend.

~~~
michaelmrose
Because python or Javascript aren't a thing?

~~~
hota_mazi
This is a similar straw man to someone claiming the trend of cars is clearly
going electric and you saying "I doubt it, look at all these gas propelled
cars we have today".

Python and Javascript are going to be around for a while, sure, but 1) they
are also moving toward static type safety and 2) fewer and fewer projects will
be started in these languages because statically typed alternatives are a
better choice across the board.

~~~
michaelmrose
Define strawman:

"an intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument."

The parent poster stated that clojures days were numbered because in his
opinion statically typed languages were becoming increasingly popular and
Clojure didn't follow this trend.

I specifically mentioned JavaScript and python because people have been
extolling the virtues of static typing literally before either shipped, while
both rose to prominence, and became wildly popular. I'm arguing that neither
posters personal preference nor even a correctly assessed trend in computer
language design is by itself a useful tool to predict the future success of a
given language.

This especially rings false when the same prediction is made several decades
in a row.

I wont even address your analogy because analogies are like buttholes.
Everyone has one and yours stink.

------
roenxi
Tempting to interpret this as the last major issue in Clojure use (error
messages) being resolved with the introduction of spec. Consensus on concerns
seem to be dissolving away from runtime issues to softer community management
issues ("documentation", which is very context specific, and "startup time"
which is important but precisely not an issue while running Clojure).

I do suspect that the survey is under-weighting how much beginners must
struggle to navigate setting up CLASSPATH. If you don't come to Clojure from
Java then the toolchain is a bit intimidating with whatever a Maven is,
followed by a process of trying to follow what both Java and Clojure tools are
doing. This is one area Clojure compares very poorly with, eg, C (similarly
awful setup process, but usually all the burden is shouldered by the
distribution provider) or Python (use pip).

It is interesting coming at Clojure from a Debian background at how resistant
Leiningen has been to being integrated into the Debian apt archive. I think
the package was removed in 2014 and only came back in 2018; so still isn't in
the most recent stable. Given that Leiningen is itself probably the first
choice of tool to manage dependencies, this raises questions about the
technical underbelly of the tools used to build Clojure programs.

~~~
mullr
> I do suspect that the survey is under-weighting how much beginners must
> struggle to navigate setting up CLASSPATH. If you don't come to Clojure from
> Java then the toolchain is a bit intimidating with whatever a Maven is,
> followed by a process of trying to follow what both Java and Clojure tools
> are doing. This is one area Clojure compares very poorly with, eg, C
> (similarly awful setup process, but usually all the burden is shouldered by
> the distribution provider) or Python (use pip).

The Clojure answer is similar to the python one: use lein. This basically
solves all classpath issues. In the 3 years I used Clojure professionally,
there were only small handful of times I had to deal with the classpath
directly, and that was only for pretty exotic packaging issues.

> It is interesting coming at Clojure from a Debian background at how
> resistant Leiningen has been to being integrated into the Debian apt
> archive. I think the package was removed in 2014 and only came back in 2018;
> so still isn't in the most recent stable. Given that Leiningen is itself
> probably the first choice of tool to manage dependencies, this raises
> questions about the technical underbelly of the tools used to build Clojure
> programs.

What questions does it raise? Debian doesn't deal gracefully with _any_
external dependency management systems, as far as I know.

~~~
roenxi
> The Clojure answer is similar to the python one: use lein. This basically
> solves all classpath issues.

Most of them. I struggled a lot with the specific case of "I have jogl
installed through apt and I want to use it in a Clojure lein setup".

> In the 3 years I used Clojure professionally

That is why I think the issue is underappreciated. Java provides a very
comprehensive set of concepts to deal with making Java code run everywhere,
and that sort of thing is just baggage when trying to learn a language as an
amateur on one system. I expect it becomes a feature when something needs to
be done professionally and platform is no longer a given.

> What questions does it raise?

* In a language that requires a lot of probably-new mental models to understand, how much extra burden is created if mistakes are made configuring dependency management?

* Can a novice successfully identify what is going wrong if they muck up their dependencies in a 3rd party tool?

* Will a novice identify that they should be using a 3rd party tool to manage their dependencies, rather than relying on other mechanisms that might be familiar to them?

* Is the hosted nature of Clojure creating interesting new failure modes for novices in the build system as issues might now straddle two languages?

These aren't questions that a professional would encounter, I expect being
across complicated build systems is sort of how things are. But the leap from
pure Clojure, having fun in the repl, to pure Clojure + a library is a very
steep learning curve. The quality of the project setup has to go up a long
way. At the moment, based purely on that learning curve, it must be one of the
early barriers that causes beginners to drop the language. I'm surprised it
doesn't get mentioned in the survey.

Watching Rich's talks, I always got the impression that dependencies in
general are an outstanding to-be-thought-about problem.

> Debian doesn't deal gracefully with any external dependency management
> systems, as far as I know.

External dependency management systems fail to meet Debian user's expectations
of quality and stability, tyvm :). Yeah, you're right.

~~~
mullr
I've struggled with jogl as well. Clojure being hosted is a definitely a
double-edged sword; while it makes it possible to use something like jogl,
actually doing so can require you know something (or a lot of things) about
the underlying platform.

The questions you raise here are real issues. I've been able to scaffold
things for newcomers to the language in the past, but I can easily imagine how
they could go off the rails without some guidance. I believe that the new
"deps.edn" mechanism is meant to be the official, paved path for dependency
and platform interaction in the future. But until everybody is using it, there
will be two ways of doing things and the confusions that goes with having a
choice. Perhaps it's necessary to move the platform forward.

------
yogthos
This was an interesting tidbit as well from another analysis [1]:

This year’s survey also included a question about how long people had been
programming professionally. 1 in 10 Clojure users have over 20+ years of
developing experience; 49% had over 10+ years of experience. In comparison,
only 42% of JVM developers have that much programming experience.

Clojure having a higher than average percentage of experienced developers
directly contributes to the quality of the language and the ecosystem around
it.

[1]
[https://jaxenter.com/clojure-2019-java-8-functional-155236.h...](https://jaxenter.com/clojure-2019-java-8-functional-155236.html)

~~~
darksaints
Percentages don't create software, people do. Absolute numbers are definitely
more important for ecosystems. I'd wager that for every 1 clojure dev with 20+
years experience, Java has 100.

I'd always consider language power to be an amplifier of experience...a 20+
year veteran that knows clojure like the back of his hand is going to be more
productive than a java dev of similar experience. But the community size gap
is huge. I deal with this as a scala programmer quite a bit. The ecosystem is
pretty great for how small it is, but it's never going to be as good as java
devs have it.

~~~
yogthos
You can directly leverage everything from Java and Js ecosystems with Clojure.
So, I'm not sure I follow the argument here. If a useful library comes out, I
can still use it from Clojure while enjoying the benefits of a much better
language.

~~~
saosebastiao
_You_ were the one to make the comparison to other JVM developers. Not sure
why you would make the comparison if your whole point was that you can use
both.

Of course that point is spurious at best. Clojure devs can use java libraries
about as well as java devs can use C libraries: it's an unidiomatic nightmare
with tons of unsafe sharp edges. And java devs can even use clojure libraries,
but they don't and probably never will. Using java libs from scala is a hell
of a lot easier than using them from java, but I still avoid them like the
plague. If we're comparing the relative merits of ecosystems for different
languages, it makes sense to compare the ecosystems developed natively in that
language, not lumping in the thousands of other ecosystems that _technically_
can interop with it.

My point is that the clojure ecosystem is weak in comparison to other more
popular languages because experience in absolute quantities matter far more
than percentages. The Arc ecosystem basically consists of a single 20+ year
veteran, Paul Graham. That's 100% veteran composition. According to your line
of argument, they surely must have the world's greatest programming language
ecosystem. Does it?

At best, the clojure ecosystem can claim to be good enough for most uses.
That's certainly a lot better than the vast majority of languages. I'd be
overjoyed if SML, Pony, MiniZinc, or Mercury had the ecosystem that clojure
enjoys. But compared to Javascript, Java, Python, C++, C, Javascript, Swift,
Ruby, etc., it's not even close.

~~~
yogthos
Clojure was designed to be a hosted language from the start, and it embraces
the underlying ecosystem. There are plenty of Clojure libraries that use Java
libraries internally and provide an idiomatic API. Having a mature ecosystem
to lean on is just practical. For example, take a look at Apache MX Net
bindings, HTTP Kit, clj-http, clj-pdf, and so on. All these libraries leverage
the host ecosystem. There's absolutely no value in reinventing the wheel here.
And the interop nightmare you're imagining simply doesn't exist in practice.

>My point is that the clojure ecosystem is weak in comparison to other more
popular languages because experience in absolute quantities matter far more
than percentages.

And yet in 8 years of working with Clojure I have yet to run into a situation
where the ecosystem failed me.

>But compared to Javascript, Java, Python, C++, C, Javascript, Swift, Ruby,
etc., it's not even close.

And Clojure leverages both Java and Javascript ecosystems directly. The whole
ClojureScript ecosystem is based around React. When you write web apps you
build them on top of React components, and other Js libraries. And this is how
seamless interop is:

[https://github.com/yogthos/semantic-ui-
example/blob/master/s...](https://github.com/yogthos/semantic-ui-
example/blob/master/src/semantic_ui_example/core.cljs)

The ecosystem is not an interesting problem to solve. Interesting things are
happening in the code you write. The business logic of your application is
where the language matters. Even when interop is unsafe you're doing it at the
edges of the application, and you treat it the same way as you would any side
effect.

------
tosh
Clojure is not only simple and thoughtfully designed/composed from first
principles it also is pragmatic (!) and reaches (JavaScript, JVM, CLR, …).

The power and joy derived from the above is incredible and (to many) even more
important: it means Clojure is not sitting idly in its own ivory tower it
plays very well with real world day to day situations.

Try to find languages that see eye to eye with Clojure here.

I’m super excited about the language and the welcoming community. Also super
fascinating to see how so many community efforts are composing and compounding
so well. I wish other languages / communities would look more closely and
adopt some (more) of it.

A bit confused with some of the comments here but then again YMMV and just
wanted to jot some of my thoughts down before I transition into some late-
night recreational coding that I was looking forward to the whole day. < 3
Clojure

------
reilly3000
Here's data on Clojure searches:
[https://trends.google.com/trends/explore?date=all&geo=US&q=c...](https://trends.google.com/trends/explore?date=all&geo=US&q=clojure)

Based on some of the comments in the thread I see there is some veracity to
the claim that interest in Clojure is leveling off or declining. However, it
has been my experience that the community embraced Clojure around 2013-14 to
the point of "irrational exuberance". The reality that the ecosystem is full
of under-engaged projects and dead ends really set in for me after I went to
Clojure / West in 2014 and saw several demos break on stage.

I want to use Clojure at work, but I'm just not productive in it yet as other
languages and I haven't found the time to build momentum with it. That said, I
still _want_ to get there.

------
msvan
I don't hear as much about Clojure these days, and I don't know if it's
because my reading habits have changed or if the community has become quieter.
My impression was that other languages have captured the zeitgeist and that
the enthusiasm for Clojure has abated. I could be wrong though.

~~~
agumonkey
It surely changed, I remember how every clojure conj was a source of
enlightenement. Reducers, Transducers .. Many Hickey talks were iconic(sic).
Now it's not as trendy.. even clojure 1.10 felt ~meh in a way. But taking a
bit of distance I thought .. it's better than having people changing the
language every 6monthes leading to js fatigue like symptoms. Slow is good. It
seems that clojure users are happy with what it is now.

~~~
casion
Clojure 1.10 targeted the #1 most irritating and requested fix to Clojure:
Error messages.

It's not exciting if you're not a Clojurist, but if you are then 1.10 was one
of the coolest releases recently.

It doesn't make for the best headlines or hypest hype: "Clojure improves on
something people hated about it."

~~~
agumonkey
Yes, agreed. It's not ~new alien abstraction to make shiny things~ RELEASE.md
but it's indeed very useful (especially on a VM hosted language)

------
iLemming
Every time something Clojure related appears in HN top - there are a bunch of
comments criticizing the language and most of them are so unfounded.

You'd start reading and even before finishing a second sentence you'd realize
- the person has no clue what they're talking about. Listen, Clojure is not a
small language like Lua - you probably won't be able to form an educated
opinion about it by trying to build something simple over a weekend.

People would say the hate JVM, when they actually mean "Java". In 3 years of
using Clojure I almost never had to even read Java code. They'd dismiss the
language immediately because it is not statically typed. If you think
maintainers of the language have no clue about type theory and completely
unaware of all the research of recent years happening in Racket, Haskell,
Julia, Agda and Idris - you are very wrong. Things you can do with
clojure.spec are absolutely mind-blowing.

If you claim that it's hard to find a Clojure job - that's not true. It is not
harder than finding a job in Scala, OCaml, Erlang, Haskell or F#. If you've
forced yourself to "love" Javascript, Python, Java or Typescript simply
because they can guarantee an employment - I'm truly sorry for you. Sometimes
I think people must be either crazy or completely ignorant - who in the right
mind would choose JSX over Hiccup and Json over EDN?

If you claim that it is hard to hire Clojure developers - that not true
either, you simply need to be ready to pay more. People come to Clojure out of
curiosity - not for dogma, not for points in résumé. Clojuristas are usually
more experienced devs, tired of all the bullshit that inevitably gets
accumulated overtime in almost every language. Clojure(script) is not a silver
bullet either. But in most-cases it simply makes sense and it just works.

------
lucidone
I've tinkered with Clojure and find it a really refreshing paradigm to work in
for building web services. However, I'm not sure I'd ever use it for something
serious - it's a hard sell to management, and it's difficult to get developers
on board to try something radically different compared to the imperative/OO
programming models. Regardless, having played with it has changed my
perception of how code ought to be structured and written. Thanks to Cognitect
and the Clojure team!

~~~
0xADEADBEE
I would dearly love to use Clojure more professionally but the problem in
every country I've worked has always been the talent pool; I struggle to hire
because Clojure devs are comparatively much harder to find. Clojure is a
wonderful language and I was firmly on the hype-train back in 2011 or so but
I'm not convinced it has much of a future outside its current niche. I would
be very happy to be proven wrong though!

I had a similar epiphany to you in that coming from a Python background,
Clojure radically changed how I thought about and approached problems. Rich
Hickey's work is fantastic and I'm very happy to have spent time in that
particular corner of the tech world.

~~~
puredanger
Clojure is easy to teach. Why not just hire good devs and teach them Clojure?
I think people overlook this too often.

~~~
huahaiy
The reason why Clojure is easy to teach on the job is that Clojure code base
is small and code are very localized.

It's impossible to be productive in a large Java code base within a month even
if you joined as a seasoned Java developer. But it is routine for a programmer
who has not even heard of Clojure before to become productive in a production
Clojure code base in two weeks. We do this all the time with our interns.

------
jraines
re: community

I hope we move on from Slack as a community hub. It's not about searchability
-- it's totally unsuitable for public/open communities. If you've been in
there recently you probably know what I mean -- it's vulnerable to griefing in
a way that, to my understanding, Slack is not interested in fixing.

~~~
puredanger
I find the Clojure Slack to be a great and helpful community. There are
certainly plenty of other Clojure chat systems on Zulip, ClojureVerse, etc.

~~~
jraines
[edit: original parent said "no idea what you mean" \- just noting b/c my
response only makes sense to that, not b/c offended by it or anything]

spoofing identities (or, I guess, making sockpuppet ones) to @-everyone and
post porn gifs & racial slurs from slackbot in #clojure

\--

Yes, the Clojure community is awesome! I only mean that Slack has problems
that allow malicious people to spoil the fun. I don't know if it's been
addressed. I logged out the last time it happened.

------
vemv
The repeated message from the authors is that clojure.core docstrings are not
gonna improve.

If you think it's an easy problem to solve, please point out a single resource
(library, website) which is 100% high-quality, comprehensive, up-to-date, IDE-
integrated, and noncontroversial. Where is it? Why haven't we all adopted it?

The facts are: we have good-enough docs, nREPL, a _massive_ corpus of beginner
material (books, videos) and real-time support from enthusiasts on Slack.

If you ain't clojuring, it's because you don't want to!

~~~
casion
I don't think that anyone believes that it's an easy problem to solve, but it
IS a problem.

I've been Clojuring since 1.0, contributed 100s of examples to Clojure docs
websites, and I still don't understand some of the .core docstrings even when
I know exactly how to use the function.

It may not be easy to solve, but it does need to be solved.

~~~
puredanger
Have you filed CLJ jira tickets about those docstrings? If not, then we are
not able to hear your concerns. We fix and improve a bunch of docstrings in
every release:
[https://dev.clojure.org/jira/secure/IssueNavigator.jspa?rese...](https://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project%3DCLJ+and+status%3DClosed+and+approval%3DOk+and+labels%3Ddocstring+order+by+fixVersion+desc)

Have you filed documentation issues on the Clojure web site? If not, we don't
know what needs to be improved. We have closed 100s of PRs and issues on the
site in the last couple years: [https://github.com/clojure/clojure-
site/issues?utf8=%E2%9C%9...](https://github.com/clojure/clojure-
site/issues?utf8=%E2%9C%93&q=is%3Aclosed)

~~~
mr_custard
I'd like to highlight an issue with the docstrings as they stand. It has been
stated by Rich himself on Jira that he doesn't like or want usage examples in
docstrings. However, it would seem that many other people would love to see
exactly that; myself included.

He made this clear a few years ago - I don't know if he has changed his mind
since?

This would probably help beginners more than anybody else.

~~~
puredanger
docstrings are intended to be a concise statement of what the function does
and we would like to stick with that.

Examples are also great. We would love to have documentation pages (or even
doc functions in the repl) that combine multiple sources of information to
help you out (docstrings, examples, see alsos, etc). That stuff does not have
to be "in the docstring" for it to be available to you as a user.

For example, clojuredocs.org does exactly this, combining multiple sources of
information into one combined page (ex:
[http://clojuredocs.org/clojure.core/zipmap](http://clojuredocs.org/clojure.core/zipmap)).
There used to be an api for clojuredocs.org and a repl lib you could use that
would give you an additional function to get those examples at the repl too (I
think that fell out of maintenance).

The summary is, we can both have docstrings that don't include examples AND
provide examples by merging docstrings with other things for the user.

~~~
mr_custard
Thanks for explaining the rationale, as well as future hopes and plans for
documentation.

------
bsaul
What's the story on clojure and compile-time type safety ?

I've asked a clojure dev the other day about it and he told me this was
experimental and not very common.

~~~
fulafel
It's a dynamic language, if you must have static typing over Clojure it's not
for you. (You can of course do a lot of other things at compile time via
macros)

