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.
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.