What happened to Clojure? Was it just a fad, or are people still using it in their day jobs? Are people still hiring Clojure devs? If you write Clojure at work, are you happy with it?
I work for one of the big "brand name" companies (I don't want to say which, but it's on the "companies using Clojure page"), and on my team we try and start all new projects to use Clojure.
Frankly, I love it. After the "zen" of lisp clicked for me, Clojure gave me an OS/2-style "Better Java Than Java". Suddenly I was able to compose standard JVM library stuff in a more-natural and easy way than I could in vanilla Java, I was able to easily define relatively-well-optimized persistent data structures, and I could quickly provide new semantics to the language as I saw fit. Also, the Clojure REPL provides an amazing level of increased productivity.
Do I miss the Hindley-Milner type system from my last job? A bit, but surprisingly it doesn't bother me as much as I thought with Clojure.
I don't know if Clojure was just a fad, but I think that it'll always have a loyal fanbase, like mosts Lisps.
We've been using a full Clojure stack (front-end + backend) in production for nearly 4 years and very happy with it (6-8 people full time). But that is very much anecdotal. I guess one thing to note is that the language is very stable, there are very few (if any) breaking changes and a 4 year old library will "just work" most of the time. Even more amazing is that it's trivial to port 40 year old ideas from (Common)Lisp if you're so inclined, or interface with a known good Java implementation. To me that is a big plus, personally I wouldn't even want a ton of extra features in Clojure ... the language is fine and libraries fill in the rest. It does give the impression that not a lot of happening and that it might be fading or boring, but in a lot of settings boring is actually a good thing. The amount of times some NodeJS or Python thing changed from underneath me and I needed to rework an entire codepath or build infrastructure just because the language changed their mind on how things should be done are gladly behind me with Clojure!
My feeling (and personal experience) is that the state Clojure is in now is so solid there's not a lot to talk about. Every time I take a peek at the JS ecosystem there's a new flavor or build tool.
I've been making a living using Clojure for a few years now as a solo dev and I don't feel the language is lacking in anything I would care much about. I started with reagent not knowing anything about react or having any Clojure experience and was immediately productive. I was able to augment part of a webapp I had in production in no time due instant feedback loops from the REPL and figwheel. The language is being iterated on but it has already been in such a state in that I'm not keeping up with what's new because I'm able to solve any problem I need to already.
I'm extremely happy with it. I have a lot of interests other than programming and I feel that Clojure allows me to deliver complex projects on time without driving me insane or having to keep up with new trends.
Your cheapest plan offers 512MB of RAM for 5 Euros a month. There's well over 5 competitors who can get you quadruple that amount of RAM and maybe even double the storage for half that price per month. This is due to renting out space at datacenters, no? I'm no hosting expert.
Thanks for looking into the service. We're certainly not the cheapest in terms of pricing but I would also warn against using RAM prices as the sole way to gauge a service.
To drive low prices a lot of VPS providers tend to have a very liberal way of playing with overcommit, which we don't do. The same goes for CPU.
Our instances should be considered to higher-end families such as the C3 and here you'll see we're playing in the same field in terms of prices.
It's due to us offering some guarantees on what you get, and therefore not over provisioning our hardware :)
Many of our clients choose us for performance (IOPS, memory guarantees, etc...), and our geographic and legal situation (no connection to 5 eyes countries, strong privacy laws).
The industry can rip Clojure from my cold, dead hands. It's still used in smaller teams at a lot of places including some of the BigCos. It's a simple joy to use and it is a damn shame it's not more popular than it is, but I don't think it is a fad.
The cancellation of a few major Clojure conferances hasn’t helped. I’m guessing it speaks to demand.
I used Clojure for a long time, professionally. Not much any more. Main issue is that the language is not very readable (a pain point mentioned in these slides) and very hard to find people to work in it. Also more than any other language Clojure is very sensitive to typos in your code. A misspelled keyword results in nil accidentally flowing through your app. It was frustrating to spend time on scaffolding everywhere to catch these things.
Also the Clojure language had a huge growth period around 1.1-1.5 which sparked a lot of excitement and spurred a lot of community growth. But since then, most of the exciting features have been adapted to other mainstream languages either as features or libraries, and most senior developers I know prefer to take the path of least resistance, which includes avoiding less-mainstream languages and frameworks. So instead of using Clojure with Compojure, it's common to move to Java with Dropwizard, or slightly less analogous, JavaScript with Express.js. And instead of using ClojureScript with Om, people mostly jumped to JavaScript + React.
Edit: Removed comment about Om, since I must be misremembering something. Om uses React and has since the first commit.
What are you referring to by "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API"?
Om uses React, it didn't predate it or anything. Many of the things Om tried are more relevant to things like Redux, not React proper, so I'm not sure what your comment is referring to.
And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.
Apparently I was remembering Pedestal. See my other comment.
> Many of the things Om tried are more relevant to things like Redux
> And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.
These are great evidence for my point, that Clojure has worked as a testing ground for features which more mainstream languages and frameworks then adopted.
I don't think I was clear enough. Yes, React (and others) has adopted things from Clojure/script, but to me, that's a sign you're using inferior tools that are several years behind.
E.g., I used to do a lot of PHP, and my last PHP project was in Laravel, which is heavily influenced by Rails, and PHP 7. Many people touted "Modern PHP is just as good as Python/Ruby/Js!" but missed the point that they'd been using tools with inferior capabilities for years.
Re. your edit, which erased "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API": I’m pretty sure that the coment you mention referred to reagent (which builds on top of React as much as om).
My memory is apparently failing me, but I remember it being one of the very first "reactive" web frameworks, before React came out, and being made by the makers of either Clojure or Datomic (before they were Cognitect) and possibly also David Nolan. And I remember them discontinuing it after React came out, saying something along the lines of "We had this idea before React came out, but our method involved explicitly changing UI when state was updated, whereas React does that automatically for you and in hindsight that was a great improvement over our idea. So we're discontinuing this and going to change the focus of the project to work with React instead." I'm pretty sure the project had a slightly longer name than Om, and was a big thing for a total of a year, where everyone jumped on board and jumped off again. Unfortunately I think I mixed this up with Om / OmNext.
---
EDIT: Oh! Just figured it out: Pedastal. Yep, originally made by Relevance Inc.
> "But unlike in Pedestal App, you don't have to worry about how fine-grained changes to your App model map to the UI."
That's the part I was remembering.
> "So there is clearly conceptual overlap between Pedestal and ReactJS. Further, David Nolen's work on Om has shown that ReactJS and ClojureScript work very well together."
That's probably why I got this mixed up with Om. This all happened about 4 years ago so I guess my memory isn't as fresh.
>>A misspelled keyword results in nil accidentally flowing through your app.
Some dynamic languages, worked around this issue in the 90's. Perl for example, if you use 'use strict; use warnings' will catch most of these misadventures.
Having said that, only the most novice programmers make these kind of mistakes. Like the absolute beginners, in the first day or two of exposure to programming.
As a rule almost any shop these days write unit test cases, so that should flush out these kind of bugs.
EDIT: Why the downvotes? People seriously work with programmers whose biggest incompetence at work is typos? Or you think writing unit test cases is bad?
With all due respect, I think your argument is a little silly. Typos are the one mistake that programmers never stop making no matter how experienced they are, in my experience. For the same reason, you can pick up a book by an experienced, established writer and find typos in it as well.
It's useful for your tools to help you catch basic mistakes like that instead of just saying you should work with programmers who are competent enough to never write typos.
I don't think we are talking about that kind of typos. But there is a often a big dip in quality of people, who routinely struggle to write a half decent working program without making these kind of mistakes.
Sure every once in a while its possible for any one to drop in a spelling mistake, but those are rare situations in code. Mostly because code is often not a dead piece of documentation, which is read and auto corrected in the human brain. Code works on a computer with well defined interfaces and protocols.
Think of it this way, would you hire a programmer who often makes typos, to write shell scripts that have 'rm -rf'?
If you wouldn't, how often do you trust these people to execute DROP DATABASE <typo_database_name_which_happens_to_be_real>?
There is a big difference between programmers who can put in typos in a sentence in a code comment, and the kind of ones we are talking about.
I've deployed tens of thousands of lines of Clojure for a company over several years, and I still find that I occasionally destructure a map with the wrong keyword and I end up with nil accidentally. It's frustrating as much now as it has ever been. Because the app just crashes instead of a simple compiler check that most languages would offer to capture simple stuff like this.
They just disagree without explaining why. Anyways, I sometimes have typos in my Clojure code, but once I follow through with your mental model and just reproduce the problem in REPL it is easy to find these sort of bugs.
I'm not sure, but if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names, write functions hundreds of lines long, can't modularize code, write 3 nested for loops, or write nested if's where '&&' suffices.
Then you are having far bigger problems related to project management, hiring and overall direction in which you are running your team/company.
Clojure as a tool doesn't aim to fix these kind of problems. And it can be argued no tool will fix these problems.
Code indentation has been automated away since like 10 years or ago or maybe even more.
Vim, Emacs, Atom, Sublime Text, Visual Studio, Eclipse, IntelliJ, NetBeans can all auto-indent code for you. Combined with linters they can also automate stylistic checks and coding convention.
I don't know anyone who indents code themselves. The editor/IDE does it for them.
Indenting code is certainly not a code review check. No sane workplace should waste a senior developer's precious time commenting about indentation problems during code reviews. It is a tooling check that is part of CI/CD.
Clojure use has been growing steadily, and lots of companies are hiring. In a recent JVM survery of 10K people Clojure came in as the second most used language after Java https://snyk.io/blog/jvm-ecosystem-report-2018
My team has been working with Clojure for the past 8 years, and we're extremely happy with it.
These stats look highly suspect with Clojure:Scala = 1.6. Here in London the jobs boards Angel.co and Indeed.com have Scala:Clojure at 3.6 and 19.6 respectively.
It's one of the most comprehensive surveys to date. Meanwhile, the job numbers can relate to many factors. For example, there could be more turn around for Scala jobs.
"Welcome to the largest survey ever of Java developers ... The survey was conducted by publishing its availability to the Java community at large (via social media primarily), to Java User Groups around the world, including the Virtual JUG, and to subscribers of Java Magazine, the Java bimonthly publication from Oracle Corp."
So the sample is heavily biased and doesn't include the population of JVM users who have never touched Java.
That's very likely the case, but presumably you'd get an even sampling from the users of other languages. It would be interesting to see some more surveys focusing on the larger JVM ecosystem though.
We've been using Clojure for 3 years and ClojureScript for 1.5 years. We're actively converting more of our legacy codebase to Clojure/Script.
It's been a great choice for us and even the skeptics have become converts over time. I think it's a joy to work with and allows us to reason about our problems and solve them better than many alternatives.
Clojure is still around and a great language for experienced devs. But the experience for newcomers is much less attractive than for other languages, which is preventing growth. Also, the largest Clojure community is the Slack channel, which is hidden from the rest of the world.
I really wish the community would move away from using Slack. It's completely opaque to most people and anything past the last couple days gets lost to the ether.
Yes, I know you can find it on some archiving site, but it's non-intuitive. Wish they'd move to Discord or Matrix or... pretty much anything else.
I regularly use Clojure at work, even though I am usually a sole contributor because other people are not willing to use anything other than Python, Go, Java. The primitives for doing concurrent and parallel programming is just so nice that I can't think of living without it. Go has similar solutions though. The biggest advantage is to have a concise small code base that does exactly you want without dancing around language related boilerplate.
While other posters comment that "Clojure still works", IIRC the "promise" was that Clojure/Lisp would be much, much more productive, and that claim I feel like must been disproved in daily work, otherwise Clojure would still a main topic around here.
I think individual developers are most likely to become much, much more productive when using Clojure/Lisp vs. Java, C#, and the like, but software development teams are unlikely to experience the same benefits.
And it's not even because Clojure is bad for teams, it's because teams often form because there are nontechnical stakeholders, and suddenly an individual contributor's code-writing productivity is a much smaller factor when compared to the communication practices and other parts of the development process outside of writing code.
It is (sadly) not clear at all that programming language popularity (or rather, "online buzz" around a language which is all you can measure) correlates strongly with productivity.
I can only speak for myself, but I'm definitely much, much more productive using Clojure. I think its absence from HN is more reflective of a less-than-stellar onboarding experience for newcomers, and HN's general neophilia.
If there is one think about humanity that is worth to note is that the shittier alternative always wins. This is true from money through computer architectures to programming languages.
We use Clojure for the whole backend, Python for machine learning, and JS for frontend at Motiva AI. It's the fourth company that I worked at (UK and US) with Clojure as one of the main languages. I'd say hiring Clojure devs has been one of the best perks for working with Clojure. Consistently high quality people that I've had the honour to work with.
At Motiva, we've dabbled in other languages like Haskell, Scala, Rust, Go, etc. but Clojure has been what sticks for us on the backend team https://github.com/Motiva-AI. We are a fully distributed remote team and we are hiring. Drop me an email.
ClojureScript also seems to gain traction. Quite impressive when you consider that Clojure is a language/ecosystem not driven/backed by one of the larger tech companies.
We're using it happily at Yieldbot. We're an ad network, and the core matching technology (which finds relevant ads based on the contents of the page and decides which one to show and how much to bid) is all Clojure. All the data science stuff is Clojure (it's been great with Spark and pretty good with Storm). The data pipeline is all Clojure now. The central database for ad campaigns and such is Datomic. The APIs for the frontends are moving to Clojure.
ClojureScript never caught on for the front-end work. There are some substantial services for which Elixir was chosen instead of Clojure.
It's interesting that in the current state of software development, a programming language that have been stable for not even a year might be considered obsolete.
A perennial problem in Clojure is libraries that reach a mostly "done" state tend to look inactive to outsiders, because the language is so stable there's almost no maintenance work.
So inevitably, someone will ask "Is lib foo still being used? The last commit was over 8 months ago" and then people have to chime in, "yes, it's still in heavy use".
Several languages have this problem, e.g. Common Lisp. It would be nice if developers of libraries like this at least updated their copyright annually, as an indicator that they and the project are still alive.
Who is the indicator for though? Wouldn't users of that language quickly come to expect that inactive is not necessarily dead or useless? (Especially with Common Lisp, stuff decades old is still useful.) And I find outsiders unlikely to care that much, it's just a nit random passerbys will make when they think they need to comment on something, rather than actually informing a serious decision.
It's also kind of pointless to "update the copyright year" for individual works tied to your name, since the copyright lasts x years after your death. If anonymous/pseudonymous, then it's like 95 years after initial publication date, and you can't just extend that arbitrarily by updating the base year and nothing else every year..
I think there needs to be something like the Apache foundation for Clojure libraries, not handling major dev work, but maintaining working libraries over time.
well... yeah ? there are entire companies of thousand of electrical engineers working in LL. They just don't come and post about it to hackernews and make PLC projects in github, they do their 9-5 job and that's all.
>They just don't come and post about it to hackernews and make PLC projects in github
Same logic applies to clojure. I think that's the point he's making. Everyone and their 12 year old nephew rockstar developer has questions about java. I also find that clojure questions nowadays are mainly asked in the clojurians slack organization. Immediate feedback is more attractive than waiting around hoping for an answer in stackoverflow.
Personally I prefer StackOverflow. SO is a wiki and it's likely my question and others' comments and answers will help someone else in the future.
With any chat interface, it feels like your question may be lost if it's not immediately answered and it's often hard to follow discussions with multiple people chatting. With SO I will spend time to try and formulate a clear question. In general with slack or any other chat I may feel out the room first as it will be a waste of my time writing a detailed question if no one is around to answer.
Perhaps some sort of SO integration into Slack would be the best of both worlds?
While Slack is the most popular forum, there's also Clojureverse.org, which aims to be a more threaded and permanent repository of Clojure discussions and knowledge.
That's because TIOBE derives metrics from search results. Which means every time some one searches 'Python, the snake', that also gets counted as 'Python, the programming language'.
Most people looking for help on the internet are searching:
"How do I do X in shell?"
No of people looking for help with the word 'Bash' are likely to be lower.
That's one reason why TIOBE is sometimes way off the real trends.
I like the CloudFoundry report [1] better as a reflection of what businesses are actually using rather than search engine metrics (TIOBE) which are overly influenced by controversy and search engine methodologies than actual usage. However it's no prettier a picture, almost no functional languages in the list at all, only Scala making a significant dent (and you can debate whether that is functional or not). Other JVM languages like Groovy are significantly ahead of Clojure in all rankings.
> Other JVM languages like Groovy are significantly ahead of Clojure in all rankings.
Apache Groovy fluctuates on TIOBE a lot. Six months ago it was at the same 50-ish position as Clojure, which is its usual ranking. It's shot up only in the past 6 months, which has also happened a lot in the past and is always followed by a sudden fall -- perhaps someone's gaming the search engine rankings. On Redmonk, Groovy and Clojure have ranked equal-ish for a long time. In the CloudFoundry report, Groovy is at the same very low rank as Others which would include Clojure if present.
So Groovy and Clojure are at the same ranking in all rankings I've looked at.
