Other people have touched on this, but I think one's ability to be productive in a language is highly correlated with how much of the language (and project domain) they can "keep in their head" at a time.
This is why Go is my (and seemingly a lot of other people's) go-to "get shit done" language, I can write and edit code for hours without having to think about (too many) footguns or hunt for docs and esoterica.
I can write and edit C++ for hours without thinking too much too, and I’m no language lawyer. Almost all code one encounters in the wild is not particularly esoteric.
> but I think one's ability to be productive in a language is highly correlated with how much of the language (and project domain) they can "keep in their head" at a time.
I disagree. I'd say productivity has very little to do with language familiarity and way more to do with ecosystem familiarity. C++ is hard because the ecosystem has no real entry point and several "script language to write a script language to write a compilation definition to write a script language to compile a project" build systems. (Who's familiar with M4?)
But when you hit the edge of your language, it will be a very painful experience, with disgusting, unmaintainable workarounds.
Mind you, I’m not thinking of some obscure thing that is only possible in Lisps, as in my experience these are seldom required, and code generation is always an option.
Go is hilariously ill-designed from this perspective, it gives you the common 80%, but has no answers for the remaining 20%. Generics does improve it a bit, but there are so many edge cases that it is simply sad to see it in a supposedly modern language.
This is why Go is my (and seemingly a lot of other people's) go-to "get shit done" language, I can write and edit code for hours without having to think about (too many) footguns or hunt for docs and esoterica.