> it's better to have one well-defined way of doing things in a language, instead of adding the mental overhead of deciding between one or the other That was t

> it's better to have one well-defined way of doing things in a language, instead of adding the mental overhead of deciding between one or the other That was the hypothesis of Golang, for sure. I think we've seen that it is true in specific contexts. It seems like it's been particularly valuable to massive teams with less-experienced developers coming from academic computer science backgrounds, frequent turnover and high-coordination projects. I don't think that property has proven to be valuable more globally. Consistency for consistency's sake is particularly costly when the "consistent" solution has significant downsides in some contexts. On small teams, having consistency result from actual alignment is incredibly valuable, and a sign of a high-performing team. In those contexts I haven't seen consistency itself, enforced by an outside group and especially without a way to work around it when the "consistent" approach has a reason it sucks for a particular application, be similarly valuable.