I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.
The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired.
Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem.
At least with Java you get Spring and this is how you do endpoint, this is how you connect to the database, and so on. The structure is suboptimal and redundant but at least they are getting some guidance which are most likely already familiar with.
In Clojure, as a lead of the project, you would have to do the same but now it would be up to you to define all of that guidance. The question is, are you better at this than entire organization that supports Spring?
The only situation I see where Clojure would realistically be beneficial is when you only get like world class developers who know what they are doing and can work together.
I can't work on a Clojure project with a person that is unable to go through something like Let over Lambda with full understanding of the code examples and trust they will be able to make good decisions when building abstractions with macros.
Isn't this a cultural, organizational problem? You said your original developers left or moved on to management and your new hires are rather inexperienced. Wouldn't it be a wiser long term strategy to facilitate learning and knowledge retention through mentoring, documentation, teaching and attractive technical career tracks?
For example there are several popular open source libs/solutions to manage application state and structure declaratively. And it is well known in the Clojure community that macros are a double-edged sword and should be used to solve specific problems.
I agree that Clojure is kind of a second (plus) language. But I also think there is a reasonable path from writing simple Clojure to wielding the more powerful features.
I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?
I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.
Which is why hospitals really shouldn't be writing software.
And why, as a developer, you want to be working for a software company where your work is generating revenue, not somewhere where you are a cost to be cut.
I guess I'm fortunate enough to have only worked in places with high hiring filter and that can attract good talent. In an environment like yours, I'm not sure what language should be used, I'd say an old version of Java like 1.6, newer versions have become less rigid and less explicit so might make them harder.
Yes; that's my latter point - it could easily have been a bad technical choice. But that doesn't really validate the "big mess"-style criticism, which I have mostly found to be untrue.
The first time you see a technology you immediately see things that solve some of problems you have, especially because authors tend to market pros more aggressively than cons.
Finding issues with technology takes some experience handling it.
For a relatively new thing that is in growth stage there is disproportionate amount of people who just joined and so have skewed perception.
I also thing people who would write about a product would usually write quite quickly after adoption but then won't follow up later after they got some experience.
