I think this is where Rob Pike got it backwards (in terms of one of his stated goal for Go).
Go is a very effective tool in the hands of experienced programmers, without having to pay the cognitive load price of 'Mommy' languages. I am reminded of Bryan Cantrill's rant regarding threads in this context.
Writing solid software is hard. It takes skill, experience, and serious battle scars. Tools and languages can help, but at the end of the day, it comes down to the team that writes the code.
Even the most experienced programmer can’t hold all of a million line codebase in his or her head. And that is the issue with a language like Go - you can be careful about the code you write but it doesn’t have static analysis enforceable constraints on code other people write that interacts with your code / data.
That is a seriously ridiculous proposition in my opinion. If you find yourself involved in a project that requires you to hold a "million" lines of code in your head, refer to above point I made regarding "team". Something has gone seriously wrong somewhere if that is the situation.
This should not be news to this audience on HN: proper software architecture, design, and development processes trump "language" any day, any time, any planet. Conversely, even the most 'profoundly correct' language in the hands of unprepared development teams can result in software disasters.
The human factor is still paramount in software development. That is my experience after decades in this profession and is not mere conjecture.
Go is a very effective tool in the hands of experienced programmers, without having to pay the cognitive load price of 'Mommy' languages. I am reminded of Bryan Cantrill's rant regarding threads in this context.
Writing solid software is hard. It takes skill, experience, and serious battle scars. Tools and languages can help, but at the end of the day, it comes down to the team that writes the code.