Go is the opposite. It's great, as you say, because it's dirt simple. It's a brutalist get-the-job-done kind of language, and I think if I were to start a company working with other engineers, I'd absolutely choose Go for that reason. It's easy to read. It's easy to reason about. And there's very little implicitness in it.
Are you aware that you're referencing the Python mantra with that? Feel free to Google it, it's from 2004.
There should be one-- and preferably only one --obvious way to do it.
the Python mantra with that?
While I love Ruby, I was looking forward to some of that "one way to do things" simplicity I'd been promised by Python.
Boy... were my hopes crushed. There are a lot of possible ways to do any given thing, from iteration to package/import structures, etc.
For the most part it seems like the proliferation of options in Python is pretty sane; I can generally see why each choice was made to address existing pain points. So kudos to Python for that. But man, did they leave "one way to do it" behind a loooong time ago.
And they honestly never really adhered to it either. It was just a knee-jerk reaction to a (I believe Haskell) presentation that said something like "we got n ways to do x", where n was in the double digits and x was something extremely uninteresting like looping over an array.
Can't really recall details though, it was old knowledge by the time I Heard about it around 2010 and a quick Google didn't help me dig it up
with some being slower than others.
It's certainly easy to think of situations where they do matter, but unless your project is FaaS (Fibonacci As A Service) probably not.
All the inefficiencies add up, at scale. a 3% inefficiency means you're spending ~3% more on compute. CI takes longer. Dev velocity decreases.