Great list of why one can love and hate Go. I really did enjoy writing it but you never get the sense that you can be truly certain your code is robust because of subtle behaviour around nil.
replies(3):
Which is really handy when shit's on fire and you need to find the error yesterday. You can just follow what happens instead of trying to figure out the cool tricks the original programmer put in with their super-expressive language.
Yes, the bug is on line 42, but it does two dozen things on the single line...
I think people often get burnt by bad abstractions in expressive languages, but it's not a problem of the language, but the author's unfamiliarity with the tools at their disposal.
If someone starts being clever with abstractions before understanding the fundamentals, it can lead to badly designed abstractions.
So I guess if there's less things to master, you can start designing good abstractions sooner.
So, in my experience, if we invest time to truly understand the tools at our disposal, expressive languages tend to be a great boon to comprehension and maintenance.
But yes, there's definitely been times early in my career where I abstracted before I understood, or had to deal with other bad abstractions
If you have to share a codebase with a large group of people with varying skill levels, limiting their ability to screw up can definitely be a feature, which a language can have or lack.
As always, it comes with tradeoffs. Would you rather have the ability to use good, expressive abstractions or remove the group’s ability to write bad ones? It probably depends on your situation and goals.