"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
Rob Pike [1]
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
This sort of "programming language designed for people we apparently have a very low opinion of" approach also greatly informed the design of Java, though Java has spent the last 20 years slowly retreating from it. It looks like Go might be following the same path; it's apparently getting generics at some point!
Can you imagine how many times Google was burned by junior devs writing C++ no matter how smart they were? Memory bugs at Google scale must be expensive. They had to come up with Go.
At scale, it might be hard to do that, however this doesn't address the key problem. One of the hallmarks of good engineering is to add technical safeguards, rather than relying solely on Smart People.
It would be comical to hear, "Hire better pilots" as an alternative to building parachutes, or fly-by-wire systems.
Every one makes mistakes. This is why we have tests, linting, code review. Our choice of tools that we use (or, in this case, create) reflect our engineering needs as well. The goal is not just to hire Smart People, but to make it _hard for people to make critical errors_. At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
> This is why we have tests, linting, code review.
None of which is related to using a dumbed-down language.
> At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
There's plenty of research around software reliability and on the sources of bugs across different languages.
Research shows that verbose languages e.g. Java don't have lower bug rates or better maintainability than expressive languages like Python.
Dumbing down a language, reducing expressiveness and introducing boilerplate does not help. If anything, it removes the attention of the developers from the core aspects of an application.
Tests, linting, and code review are all tools that we use to find mistakes before they get into production code.
A "dumbed-down" language is a tool that prevents one from being able to write certain classes of errors (e.g. some of the footguns from C).
Changing the language doesn't mean you make less mistakes, but it means that you make different kind of mistakes. I'm rather unlikely to make an error related to memory allocation in Python or Java, for example.
I know C++ and I know Rust is growing because of memory problems in C++ code. I would agree with this statement "It requires years of experience and great discipline to avoid errors in C++" from this article https://www.toptal.com/c-plus-plus/top-10-common-c-plus-plus...
Eh, I've always seen this as the counterpart of the old meme that there are no bad languages, only bad programmers.
He's not going to get many C programmers to adopt his language if he gets on stage and announces C is a crap language and anyone who thinks their code doesn't have memory bugs just hasn't found them yet. Is this asshole saying I'm bad at my job?
On the other hand, if he says that of course you, dear reader, have never coded a bug in your life - it's other programmers who do that, and this new language will help you collaborate with those poor unfortunates? That's an easier pill to swallow.
