Programmers should know their trade-offs. It's not so much that STM should be avoided, but that the use cases it was designed for don't often present themselves in production. Same with agents, core.async, metadata, etc.
So I also get a bit twitchy when I hear for wholesale use of Timbre, Component, Schema. Every one of these libraries has tradeoffs. And those tradeoffs should be understood before adopting them. As an example, if you have a need for Schema, perhaps your data model needs some refining. Maybe you need Schema at the edges of your API, but you should define why you need a library before you just adopt it wholesale.
Likewise with Timbre, often we need tight integration with Java tools, so perhaps my project really does need a "native" java logging library.
Perhaps "understand all the trade-offs" should be the mantra of programming, in any language.
Perhaps "understand all the trade-offs" should be the mantra of programming, in any language.
Yes, yes, a thousand times yes! (Perhaps too close to James Joyce, but that's not the point.) Understanding cost/benefit and making good decisions is the basis of winning a lot of games, the game of programming included! A programming shop needs to be good at the task of optimizing its programming, obviously, and as in any optimization task, cost/benefit comes into play.
A lot of his points say to offload to services such as a database or queue. It makes sense that if all you are doing in your Clojure application is some simple business logic then you won't need the more sophisticated tools for concurrency and shared state, but if you were trying to write those services in the first place, or if you need higher performance so that sending everything over a socket to a database isn't realistic, then you may need them.
This really only makes sense for service-oriented software. Not all uses of clojure attempt to saturate use of available resources, and here STM is a win.
But the OP implicitly assumed everyone was writing "production" software, assumably as part of a commercial service offering.
Although he didn't reiterate it in the STM section, up front he was pretty explicit about what he meant by "production" software, really a specific kind of production software. So the recommendations might not apply if you write a different kind.
To make my biases explicit, I mostly write webapps and data analysis on servers in the cloud. If you use Clojure in significantly different applications, these recommendations might not apply to you.
So I also get a bit twitchy when I hear for wholesale use of Timbre, Component, Schema. Every one of these libraries has tradeoffs. And those tradeoffs should be understood before adopting them. As an example, if you have a need for Schema, perhaps your data model needs some refining. Maybe you need Schema at the edges of your API, but you should define why you need a library before you just adopt it wholesale.
Likewise with Timbre, often we need tight integration with Java tools, so perhaps my project really does need a "native" java logging library.
Perhaps "understand all the trade-offs" should be the mantra of programming, in any language.