Hello all. As the title says, just want to know if there are any companies that moved away from Clojure due to any reasons and if yes, what was the reason and what was the new choice?
With programming languages, all you’re doing it picking which problems you don’t want to have to worry about and which ones you do.
When a team decides to switch programming languages, which would be a major undertaking, it’s typically for one of the following reasons:
1 - There is a deeper understanding of the problem space and the initial language doesn’t actually help the team from creating bugs that would be determimental to the continued operation of the business (eg, choosing Erlang when 9 9s of uptime is of absolute importance or a systems language when nanoseconds matter).
2 - Time has passed and there are many frustrations the team is dealing with in either maintaining - or extending - the current codebase. And there is now a belief that switching everything over to $LANGUAGE will solve those problems. This is rarely true and almost always a red herring as (typically) institutional knowledge of what the original set of problems $ORIGINAL_LANGUAGE solved are forgotten/ignored due to them not ever being a problem. But as soon as you flip the switch, the team will be acutely aware of them.
In the end - unless it’s made for a legit business reason (see: #1) - more time will pass and the same team will be frustrated with a different set of problems.
My prior team had a clojure codebase. It got swapped to some python malarkey. The clojure app was the only clojure app at the company. The original author i think made that decision in isolation—and our structure allowed for deeply independent decision making, imho to a fault. The problem was (of course)… he was the sole clojure dev before departing. I wish i had taken the time to learn it back then—my FP skills came only years later, and only later did i realize what a gem we actually had. It wasnt a huge project/system. It was scrapped because it was perceived esoteric. No one in our team argued against that claim. But bring esoteric didnt mean that it wasn’t also elegant—it probably was. I wish we had all just taken the time to learn it rather than rewrite it.
Given that Nubank uses it at the scale they operate, I doubt there are any issues with the language, but given its license (well, Nu bought Cognitect), I wouldn't consider using it, not to forget it's virtually impossible to hire Clojure developers as the interest in the language haven't grown much in the past years and it already had a very small community.
The immutable data structures seem very costly in the JVM, so basically you'd use it mainly for the power of abstraction. I'm a big fan of LISP and functional programming languages, but I have a hard time finding a good case to use Clojure, one could use Kotlin or other JVM langs and have a huge pool of great developers, and your code will be arguably more performant than from those built in Clojure.
It feels like it was just hype, people were hyped about immutability, Rich Hickey's personality etc, in reality we've faced the harsh reality that memory addresses and how the CPU works isn't in a immutable way, and the extra glue is very costly.
I've worked on some Clojure projects and as well most code looked like spaghetti, even if you'd take a look at projects developed by the core team from clojure, you'd find lots of code that is hard to comprehend, something that in other mainstream programming languages wouldn't take a genius to understand.
After using Lisp for a long time I started to believe it's a good language to write programs for myself, not to collaborate in a team.
Those are all my opinions though, interested to hear others.
My previous company did. In fairness one of the problems the company faced was way too many languages being used in-house. Combined with the difficulty in getting Clojure talent, and it was inevitable that the Clojure went out.
> Combined with the difficulty in getting Clojure talent
Why bother looking for talent in a specific language? Every reasonably intelligent (not even necessarily talented) developer can learn another high-level language in some weeks.
I killed projects in Clojure when I took over the company. Then again, I killed projects in Scala, and Python, not only including but starting with the ones I had spent more than a year building. About ten projects were killed.
My cut-off criteria at the time were: are they bringing revenue and what technical risk do they open us to (hiring, training, debt, etc.)...
As hinted, the first one I killed was in Python, and I had written about 70% of the codebase.
Lack of documentation around performance related stuff and high memory usage because of immutable data structure.
Otherwise it's great. I try to do it in my free time since most of the clojure services are stable(in terms of features) and we are just scaling it up as we see increase in traffic but it's not really helping right now.
I guess it depends what the tech stack was before?
Where I work, we were previously a ColdFusion shop when I joined, and after a false start with Scala, I introduced Clojure and it stuck: we cross-trained the CF devs and slowly rewrote the platform from the bottom up in Clojure.
We had struggled with automated deployments, and the size of servers, when we were a CF shop but after the switch to Clojure we had a fully-automated deployment pipeline, with rolling cluster updates, and much smaller servers than we needed before, running more processes than before.
The platform was written in Clojure from ground up since the team was small and rest of the company was using Clojure mostly in combination of Java.
Now most of the company moved out of Clojure for various reasons but they didn't try to write performant code and instead just chose to rewrite which I want to avoid. Try as much as possible before deciding to rewrite since rewrite is expensive given the codebase has lot of things.
When a team decides to switch programming languages, which would be a major undertaking, it’s typically for one of the following reasons:
1 - There is a deeper understanding of the problem space and the initial language doesn’t actually help the team from creating bugs that would be determimental to the continued operation of the business (eg, choosing Erlang when 9 9s of uptime is of absolute importance or a systems language when nanoseconds matter).
2 - Time has passed and there are many frustrations the team is dealing with in either maintaining - or extending - the current codebase. And there is now a belief that switching everything over to $LANGUAGE will solve those problems. This is rarely true and almost always a red herring as (typically) institutional knowledge of what the original set of problems $ORIGINAL_LANGUAGE solved are forgotten/ignored due to them not ever being a problem. But as soon as you flip the switch, the team will be acutely aware of them.
In the end - unless it’s made for a legit business reason (see: #1) - more time will pass and the same team will be frustrated with a different set of problems.