Bus factor: number of people with essential knowledge of the project such that things would grind to a halt if they were hit by a bus. [I'm by no means a Go ex

Bus factor: number of people with essential knowledge of the project such that things would grind to a halt if they were hit by a bus. [I'm by no means a Go expert, but languages are my thing and I have been following Go's development.] Go has an extreme focus on simplicity, to the extent that most of its virtues and basically all of its faults can be attributed to this. This includes simplicity of the language itself: I learned Go incidentally, by referring to a program written in it when I was implementing an undocumented protocol. You don't need to hire people who already know the language, because it hardly matters; Go basically exists within whatever language they already know. It also includes a homogenizing effect. Different projects written in C++ can use completely different corners of the language. Someone joining a Go project has very little "how is this project written" to deal with--in fact, the only advantages of Go I can think of that aren't rooted in simplicity are: gofmt, a tool (and more importantly, a convention) for standardizing code style; and goroutines, a standardized (and easy-to-learn) approach to the inherently difficult problem of concurrency (that otherwise has a great diversity of approaches). So Go expands hiring pools by being so simple it's not important that candidates have experience with it, and reduces onboarding time by making projects as homogeneous as possible.