functional languages achieve much of this at the expense of massive amounts of memory copying, and if you add concurrency to the features, because there is good reasons to, you wind up with a problem that most of the time you should be using pointers and mutexes

and this doubly applies to the compiler itself, as with most languages, the compiler is written in the language itself, via a "bootstrap" method, i have seen haskell compilations OOM kill almost as often as i've seen badly written C++

compilation requires the use of massive tree structures and this combined with a pass by value policy leads to a LOT of garbage

and no, being a good programmer is only part of the story... if we were talking about carpentry, would you agree that frilly decorative crochet pieces around the tools are going to not impede with the work at hand?

that's how i see most of the languages...

i read python, so much repetition, such a poor visual impact of the general pattern of syntax

java, so many ridiculously long names and multi-hop paths due to the OOP... and C++ and javascript both also suffer from this extremely noisy visual aspect

in Go, you can often spot a bug just by that first momentary glance by the shape of the code

it is often tempting to forget to obey one of the first laws of go: fail fast - handle the error case before you handle success, and it always bites you on the arse, and this is an example of something that can be recognised instantly at a glance by the underscore where the programmer is pretending teh error case does not matter

it almost always matters, except in a few rare cases like running out of entropy

and yes, there is several critical parts of the Go standard library that push noisy, stuttering things on you like the context library, which is used to enable clean shutdown and timeouts of threads... not saying it's perfect, just that if you follow the rules in your code you less often have to go back and debug later on when things start going wrong