But:
- good luck finding a Clojure programmer if your current one quits.
- good luck finding answers for your exotic bug/performance issue
etc.
Code is a liability, it's much more than language/VM/compiler features
This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is.
For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category).
Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?
Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.
Their negative experience is based on facts not in evidence so I can’t really comment specifically. The StackOverflow community survey results suggest their experience is at least unusual.
Whilst Clojurescript may not solve all of your JS problems re-frame is certaily an advance over React + Redux. In fact David Nolen and Clojurescript have had a big influence on the development of React.js since Peter Hunt first introduced it.
It absolutely is. As someone who's dealt with JS/TS/Coffeescript and a bunch of other "scripts" that compile, transpile to Javascript for very long time, I can honestly say: Clojurescript today is the only truly production-ready viable alt-js PL.
and you don't have to use it with React. React with immutable data structures just makes sense. Once it stops making sense for any reasons, Clojurescript community will move on to using something else.
You know how it sounds? It sounds like: "yeah I like rock music, but I think I don't like this Pink Floyd band. No, no. I never heard any of them on the radio, but Sarah once tried singing their song to me on the phone, and you know what? It was horrible. No I don't think I'm gonna ever listen to them. Not my style."
> Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.
Most people who actually try Clojure do tend to like it. There are certain annoyances as a beginner you'd have to deal with (parentheses, startup time, error messages), but once you learn it a bit - they all become really insignificant. And what's there not to like? Clojure is extremely practical, has a nice core library, it is very predictable and stable. Yeah, it is not a silver bullet but it is for sure much better than Javascript and Java (and many other popular languages).
I can't imagine why anyone would have any difficulty finding and hiring good Clojure (or really, any functional programming language) programmers.
Why nobody ever says: "good luck finding good Javascript developers"? Or good Java programmers.
Why it became a default norm: every programmer is a Javascript expert now?
In my experience: hiring Javascript developers is hard - most applicants don't even know the difference between null and undefined or can't explain how prototype chain works. And even when you find someone with good experience, there's always on-boarding period: "we're using OntagularJS 1.5, oh you heard about it, but never used it? It is similar to BrokenboneJS, but with slight differences.". And then they have to learn your conventions, debate over enabled/disabled rules in your linter, etc.
Whereas if you specifically try to hire programmers who previously tried and experimented with Clojure (even if you're not using it) - chances to get better candidates increases dramatically.
If I had to choose between hiring five JS/TS/PHP/Java/C#/Go/etc. developers with $100K/Y salary per each or hiring only three Clojure developers for $200K/Y - I would go with the latter. ROI in that case would be much, much higher. Yes, code is a liability - one messy, inexperienced coder can do so much damage that it may take months to fix it.
My anecdotal experience with posting a Clojure job online (especially in the Clojurians slack) has been several decent applicants applying in matter of a few days.