So it doesn't fit his use case. There is no silver bullet. Everything is a moneky's paw in software engineering. I look forward to the day when someone discovers a language trade-off and doesn't dramatize the entire experience.
I like reading a bit of prose about when a tool doesn't fit someone's use case. Nim has a pretty interesting approach to data sharing in concurrency, and it's more interesting to read a story of someone who got bit by it than to read a table of language features and wonder when it might prove to be a problem.
But that's not how it was phrased at all. It was more like "I liked this thing, then I didn't like it because it didn't scale in a certain aspect as I wanted to so peace". I think studies of use cases are valuable but this was not one.
I'm not sure this blog post could have been any less dramatic. He could have not written it I suppose, but he brings up valid points that are probably useful for everyone who might be using or interested in Nim. I don't think the attitude here should be "if you don't have anything good to say don't say anything at all."
This might be a tradeoff - or it might simply be a flaw. Compared to a language that provides easy composition of managed state changes (Haskell or Clojure), or an alternate model for handling these kind of updates (Erlang or Scala), what is the compensating advantage that Nim gets for this tradeoff?
Extreme portability.
Why is extreme portability opposed to multithreading?
Because each platform has its own wildly different threading semantics? (I don't actually know if this is necessarily true.)
The problem is, there's already plenty of garbage collected mostly portable languages with slightly painful FFI.
Goodbye Discovering A Language Trade-Off and Not Dramatizing the Entire Experience, and good luck.