Thankfully Clojure will go nowhere beyond a few edge places. I saw a decent sized project written in Clojure script that had to be rewritten once the original authors moved on as new hires struggled to get anything done. Small features took enormous amounts of time.
I believe that if a company wants to do software by throwing as much bodies at it as possible, they need to embrace it fully and openly. Going back to pure Java might be a good idea, as the language enables progress to be made in a "factory coding" environment pretty much by design.
(Not a judgement; this is a legit use case, even though not an environment I like to work in.)
You would think but they measured what they need and they are sure that Elixir is the right fit for their use case. They aren't a CRUD company, like 99% of others. They are doing freaky things with multiple freaky orchestrations with multiple freaky OLD-WORLD institutions. Rails aint gonna cut it.
Fair enough. I personally think that companies for which the choice of technology is gonna be the primary factor to success are as common as unicorns. I have never seen a company fail because they picked the wrong language/tech stack. But hey, if they've measured, they probably know what they are doing.
Your experience appears to be an outlier. Lots of companies are using Clojure for large scale projects, and my own team has been happily using it for nearly a decade now. The fact that your team struggled to get anything done probably says more about your team than Clojure to be honest.
Thanks to the rise of SOA, basically any language no matter how obscure can claim multiple corporate users for for what are ultimately inconsequential projects.
But as long as we're using personal anecdotes, I saw several teams using clojure at Amazon when it was more popular. Less than two years later, all of them that I knew of (I was a clojure user too, interested in its use in the company, so I was keeping track) were at some stage of abandonment or rewrite into more boring languages. If you're lucky enough to keep your team small and ideologically aligned, it might work for your team, but I have yet to see large company make a significant bet on it (as in more than a few one-off teams) and come out ahead.
Most companies don't really publish their tech stacks in the first place. However, there are a number of consulting companies, such as JUXT and Metosin, who built their entire business on Clojure consulting. Clearly there is a market for it, and if you look at the clients of these companies it's quite clear that it's not just some one off projects.
Again, my personal experience is that my team grew from 3 to around 20 people now all working exclusively with Clojure, and we've never had any problems onboarding, or being ideologically aligned.
Just because it allegedly didn't work out at Amazon doesn't really translate into sweeping assertions you're making about it.
The fault here is not the language. No new technology should be introduced into a team by a single person. It must be a group decision and everyone must participate.
Clojure and Clojurescript are great but they have a steep learning curve. You have to weigh the advantages and the inconvenience of every tech
That can happen with pretty much any technology if you hire people who can't learn new things.
The current de facto tech stack for building SPAs in ClojureScript seems to be Reagent + Re-frame (or something built on top of them). It's conceptually so close to React + Redux that I have a really hard time imagining a Redux guru who wouldn't be productive with Re-frame in two weeks.
Then of course you can have jQuery developers who absolutely cannot work with React and probably never will, and possibly vice versa (never seen that tested). Back in the day AngularJS was cool but much of the code written with it was horrible, because people wouldn't work through the tutorial which explained how to use it as a tool, not a footgun.
reply