Apparently I and my fellow Clojure devs aren't real Clojure devs. Or perhaps you mean "true" clojure developers, or "good" clojure developers. (cf. https://en.wikipedia.org/wiki/No_true_Scotsman)
And even if we were Clojure devs we've inherited multiple big Clojure codebases that were apparently written by non-Clojure devs, and heavily refactoring is not on the to-do list.
The dynamic typing and "everything is a map" can be a PITA. At the moment I'm working on a codebase that has I/O to JSON APIs, Avro schemas and postgres databases. That means that a field called "date" can be either a string, integer days since the epoch or a Java Date, and (because this codebase isn't great) there's no way of knowing without tracing the call stack.
With the right discipline (specs, obsessively normalising all data at the boundaries, good naming conventions) this wouldn't have been a problem, but that discipline is optional, and headbanging aggravation results.
(This is, of course, a generic "dynamic typing" problem, but that's a key feature of Clojure)
I didn't mean FAANG companies - these days I work for a boring 500 person SaaS company (outside London) and we have at least 50-100 engineers at £100k+, excluding equity.
I get a lot of recruiter spam on Linkedin for roles at retail banks, outsourcers, consultancies, SaaS companies, startups, etc. etc. in the £90-110k bracket. I do also get a lot of recruiter spam for laughably underpaid jobs, in particular hardware/embedded roles, which is why I switched out of embedded.
Anecdotally I've heard of people getting discounts from the dealer by buying on finance, then asserting the right to cancel within 14 days* and paying cash instead. AIUI the dealer doesn't have to accept the cash, and could take the car back, but then they lose the sale, so they generally just suck it up.
I should have added that I've had similar experiences with (old school, untyped) python codebases - absent the esoteric programmers, which is not a small difference - although with python you tend to hit performance issues if your call stacks get too deep. Ironically the JVM performance lets you dig yourself into a gnarlier pit before you have to face up to it.
Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects.
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
That's the point - if the C-level could go to prison then you'd find that mysteriously there were multiple overlapping systems of control implemented such that no one person could make a simple human error and expose reams of customer data: it would require systematic failure.
(At that point, when safety systems are in place but fail for complicated hard to predict reasons, malicious negligence is hard to prove and executives don't go to jail.)
> I suspect the hum obsession has something to do with LLMs “awareness” that their “physical selves” exist in data centers.