As an aside, the 2019 SO survey shows Clojure programmers are the best paid [1].
Most Clojure programmers I know (myself included) would not choose to go back to Java.
[1] https://insights.stackoverflow.com/survey/2019#technology-_-...
We think of hockey stick tech adoption curves as smooth exponentials, but that's not actually true. Hockey sticks demonstrate COMPLIMENT EFFECTS, which is where the latent potential for growth is suddenly activated by an external trigger. An example is broadband/youtube, described by VC Chris Dixon here: http://cdixon.org/2009/09/10/non-linearity-of-technology-ado... Another is smartphones and smartphone apps. Ruby/Rails. Scala/bigdata.
Our goal at http://www.hyperfiddle.net is to use the low-code movement to trigger complement effects in Clojure.
About a year later, I was doing a project where I felt a dynamic language would be useful, still wanted it to be pure-functional-ish, and tried Clojure, and this time started with the fundamentals, and once I got to macros, I was completely hooked on Lisp for forever.
I thought it was the coolest thing ever that I could add language features without having to understand compiler theory or anything like that.
=====
Nowadays, my work involves around 50% Java (yuck) and 50% Clojure, but a lot of my personal projects are done with Scheme, since I have to admit that I do kind of like the `define-syntax` macro system better than Clojure's.
I definitely see the "event horizon" analogy. Once you see just how much more productive you are with the language than most others, it's hard to leave.
I am freelancing for Clojure projects for already 6 years and have to say it is true you can expect better compensation in general, but this is only given
1) You are an experienced coder overall, e.g. I am 18 years in dev, and Clojure is seen as a logical high level experience conclusion
2) You can find good existing Clojure project, which is damn hard, and the line of Clojure coders for openings is usually pretty long. And many businesses are expecting to find young coders who can be.. not so well paid. The latter is a very bad approach for Clojure projects (Sorry, young guys, I have seen tons of Clojure code by many people, and it only looks good when the coder is at least 30+)
3) You can find good greenfield tech agnostic project, where your sell point is, again, your overall experience first, Clojure second
But at the end, that all keeps you very fit in many dimensions, and I am not going to give up Clojure, instead investing more
Thats true. I write clojure for living too.
But choice of programming languages in enterprises is not made by programmers.
For example, my previous employer (Jet.com) used F# partly because one of the most senior engineers liked it, but also partly because they thought it might attract some tech talent out of the shadows.
That's more an indication of scarcity than anything else. FORTRAN and COBOL programmers are also pretty well compensated.
Also, good luck getting any of these jobs.
When was the last time you've tried? I know a great deal of developers (including myself) working exclusively with Clojure and have never struggled finding a new gig.
That's a bit hard to believe.
Surely someone in this situation would settle with taking a job programming in a different language instead of going homeless?
It's also possible they placed unreasonable demands (I notice a lot of people looking for jobs in niche languages often ask to work 100% remotely too).
If you work in a niche language, you need to be ready to compromise in certain areas, such as having to relocate.
I agree, if this person was acting entirely rationally they probably would have switched to learning JS and found a job by now. My only point is that there aren't many opportunities for junior-level Clojure developers who don't stand out as exceptional in some way.
https://github.com/oprogramador/github-languages#most-failin...
https://www.benfrederickson.com/ranking-programming-language...
But trying to compare across languages by package manager traffic or something would obviously be a lot harder.
In any case apparent zero velocity, whatever it's actually tracking, definitely shows that general interest (which constantly seems high) isn't really translating to really wide adoption.
The Clojure annual survey gets more and more participants every year, so from that angle it seems to be growing.
> In the first Clojure survey in 2010, 27% of respondents reported using Clojure for work and 33% for serious hobby projects. This number has steadily grown over the years and we now see 66% using it at work and 54% using it for serious hobby projects.
https://clojure.org/news/2019/02/04/state-of-clojure-2019
It's the number of Clojure devs using Clojure for work that has consistently grown. Interesting that this has happened without the community growing in numbers.
In case of Clojure the answer is unequivocally yes. It's got a large active community around it, and there are many companies of all kinds using it in production. Whether it's growing rapidly or slowly doesn't really affect its effectiveness compared to the other options available.
The only question worth asking is whether the language has a big enough community to be sustainable
Exactly, and I'd argue Clojure was on a path to yes, but has lost momentum and is leaning toward no.
Wrong. Clojure community is only smaller in comparison to mainstream languages: Java, JS/TS, Python, Ruby, Go. Today it has more conferences than Haskell, F#, OCaml, Elm, Elixir, Erlang. More meetups and more podcasts. Just this year alone there were announcements for Clojure confs in India, Brazil, Canada, Russia and Belgium (and these are just for new ones)
> many abandoned libraries
Wrong. Clojure emphasizes modularity and composability, library that supposed to be doing one thing and well is usually just that. Besides, Clojure is also legendary for stability and backward-compatibility. I don't know any other language where you can pick a project of a few years old, update a few dependencies and still expect it to work. You don't have to re-write things every time TC39 gets browsers to support yet another Javascript feature. Read this passage from one of the Clojure libs https://github.com/candera/causatum#liveness-advisory to understand why Clojure libs don't get updated very often.
There are hundreds of Emacs packages that people still download and use but they haven't seen any updates for decades. Does that make them "abandoned"?
> no killer app
Wrong. Clojure often offers multiple choices for any domain. Being hosted makes it even broader. Yes, some knowledge of the language you're trying to interop with is required, but you don't have to be an expert to successfully build and maintain things. If someone doesn't qualify Figwheel, Re-frame, Fulcro, Lacinia, etc. as "killer apps" I don't know, maybe they are just pathologically ever unhappy.
> painful tooling
Wrong. Again. It used to be difficult, because only Emacs used to have nice support for Clojure. Today you can write Clojure in Emacs, IntelliJ, Atom, VSCode, Vim, Eclipse. And tooling is a lot nicer in comparison with other tech stacks.
So no, Clojure has never "lost the momentum". It is still growing, but less rapidly. The ecosystem has reached levels of hedonic adaptation, where people are just happily using it without too much excitement and/or frustration. Clojure has become a "boring" language. It just works. And arguably it is probably the best tool for what it is made for.
There are tons of new libraries and tools being built with Clojure every year. Some recent examples are Spectre, Crux, Metabase, Braid, Neanderthal, and many others.
Meanwhile, the tooling around Clojure is far better than vast majority of languages out there. Leiningen is a one stop shop for managing dependencies, testing, building, and packaging the application. Uberjars are effectively containers that you can drop on any system that has a JVM on it and run them. Compare this to the nightmarish tooling of Node, Python, or Ruby.
Furthermore, if you're doing web development then you get a single consistent setup with Clojure/Script, and once again benefit from superior tooling where you can reliably hot load code in the browser, something that simply doesn't work in Js, do code pruning down to function level, and minification including libraries.
There's a good reason that you rarely see companies switch from Clojure to other languages once they start using it.
[1] https://www.youtube.com/channel/UClJshc6QtMWRqIAwJy85sfA
https://trends.google.com/trends/explore?date=today%205-y&ge...
You can still be adding a few new libraries, and some new users while interest declines. Clojure had the potential to be the default Lisp, the default functional language, and perhaps the default alternative to the c family of languages. Unfortunately, it is heading towards being just another niche language. Tooling is a big problem, not because the once you learn emacs and cider it is insufficient, but because it is a pain to setup and learn emacs and cider. Not because Atom and proto-repl are bad tools, but because to get it set up you need 10 plugins and 20 config setting and it ends up being fragile - complected in a major way. Another part of the problem is that Clojure advocates vastly overvalue the what unique benefits Clojure adds things like hot reloading and the REPL. Clojure and ClojureScript might have better or more pure implementations, but everyone has some form of these features now. It isn't a compelling argument to say switch to Clojure, change programming paradigms, learn Lisp, learn emacs, learn java, so you can get a hot reload that is 15% better than what you have now.
BTW, when I started getting interested in Clojure, one of the videos I learned from was your Philly ETE presentation. So I have a lot of respect for where you are coming from, but I wish the Clojure community was less defensive, and more unified around a strategy to promote and grow the language.
>Tooling is a big problem, not because the once you learn emacs and cider it is insufficient, but because it is a pain to setup and learn emacs and cider. Not because Atom and proto-repl are bad tools, but because to get it set up you need 10 plugins and 20 config setting and it ends up being fragile - complected in a major way.
It's quite clear you haven't used Clojure tooling if that's your impression of it. Again, Clojure has some of the best tooling I've used in any language and I've been doing development for around 2 decades now. Intellij and Cursive are a fantastic combination that takes minutes to install. Calva is another great option for VS Code and it's also a one click install. Both these projects are actually being funded. Cursive is a commercial product and Calva is funded via Clojurists Together. Both Cursive and Calva show just how much the community has grown, since people and companies are willing to pay for tooling nowadays. That's a real measure of growth.
>Another part of the problem is that Clojure advocates vastly overvalue the what unique benefits Clojure adds things like hot reloading and the REPL. Clojure and ClojureScript might have better or more pure implementations, but everyone has some form of these features now.
Again, this is completely false. I'm not aware of any mainstream languages that facilitate anything remotely like this workflow: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....
>It isn't a compelling argument to say switch to Clojure, change programming paradigms, learn Lisp, learn emacs, learn java, so you can get a hot reload that is 15% better than what you have now.
Switching to Clojure provides far more benefits than just having hot reloading, and these benefits are very convincing for plenty of companies using Clojure today. These benefits also tend to appeal predominantly to experienced developers: https://insights.stackoverflow.com/survey/2019#work-_-salary...
I think it's because Clojure in general focuses on the value of things rather than the identity of things
All of this is demonstrably false as has already been discussed in the other reply.
>Exactly, and I'd argue Clojure was on a path to yes, but has lost momentum and is leaning toward no.
I don't know how you can argue that seeing how Clojure is used commercially by plenty of companies large and small nowadays. It's already been viable years ago, and its only been getting better every year. My team has been using it for nearly a decade now, and we can't think of a better option on the market today. Clojure is way past the point where it needs to show long term sustainability.
https://trends.google.com/trends/explore?date=today%205-y&ge...
Not to sound snarky, but that could be interpreted as old clojure projects can't find Clojure programmers.