>> other languages have radically different tools and practices that lead to far fewer footguns
Can you share any examples of these different tools and practices?
Can you share any examples of these different tools and practices?
They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it.
That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.
Unfortunately I also happen to not get paid to play around with languages, although I'm open to such a position if you know of any available one. I get paid to write robust software and to work with engineers that don't always have 10+ years of experience. I get paid to deal with requirements that change every bloody week because we have quick customer feedback, customers that are very vocal about wanting things a certain way and highly intolerant of software crapping the bed when they go and try their "super normal, and expectable" extreme edge case.
I've dealt with those cases across many languages across the years, and you could easily guess that I would be very desperate for the money if you find me in another job working in a dynamic language dealing with constant changes.
By the way, it's okay if you're not familiar with the concepts I brought up by name, but if you have worked with Rust, TypeScript, Haskell, Scala, Kotlin, PureScript, Elm, F#, Swift or one of many others, you're probably familiar with them. They're everyday tools to programmers using those languages, not some strange academic tool.
In my experience this is something where clojure is exceptionally good at.
I'm not trying to denigrate your experience, and I'm not pretending that we work in different industries and deal with very dissimilar problems. But if anything I learned from the years of writing software - there are no silver bullets. Every single tool has cons and pros. You can't just look at any instrument, framework, library, language through a tiny keyhole and make assumptions. And I'm not saying you have. Perhaps you have rich experience using Clojure that led you to the conclusions you made. From my perspective - I have the opposite of that. And again, it's not because I have not seen what you have. Clojure, in my opinion, compensates for the lack of static typing with a plethora of other features. Features that many other languages can't offer but are essential for me.