Item — HN Reader

> What, exactly, was gained here to justify the productivity lost while waiting?

The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right".

Also, the lost productivity that keeps getting mentioned is overblown. The minority who actually need it (a subset of those who ask for it) are, well, a minority but a loud one. I have developed in Go for 8 years. I only ever reached for generics twice and in both cases, copy pasting the implementation in different types added a insignificant effort.

> Go is a very boring language in a sense that there's very little new there

You hit it on the nail! It's boring. That's what you need when you're targeting large distributed teams and want your code base to survive decades and still be readable and navigatable by pros and amateurs alike. You don't want clever or smart. You don't want cutting edge and novel for novelty's sake. You don't want magic. You don't want to have to keep the context of 20 files in your head to understand one line of code. You don't want a syntax that can be interpreted in 10 different ways in different contexts, ... . You want the sweet spot between simple and practical.

Back to:

> Most critics of Go are well aware of its history and purported design goals.

Your comment about Go being boring and its lack of novel features, is clearly demonstrating that you've either missed or misunderstood the design goals. And many similar comments on other parts of the language from others I've interacted with is what I was basing my parent reply on.

2 comments

Right, the design goals are it is a language for people not clever enough to deal with programming languages.

"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. – Rob Pike 2"

Sources:

https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...

https://talks.golang.org/2012/splash.article

Thanks for refs.

> people not clever enough to deal with programming languages.

Add older folks to this cohort. They've lost steam, are lazier and less patient with obstacles and less fortunate with time.

You are counting older folks short.

Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash, ....among plenty of other stuff, naturally depending on project specific workloads.

Maybe it is some devs that can't fathom how to transport water buckets to the top with all those stairs.

> Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash

Very commendable — I don't touch JS that I didn't write. Forget C++ altogether :D

I didn't mean my comment as a negative — in fact, I see all those attributes as essential so one doesn't produce junk at a fast rate just cause s/he can code for 20 hour straight and refactor endlessly. Of course I know devs older than me who are still in mass production mode and don't deliberate much. In fact, I often have to ask people to slow down and seek simpler and lazier solutions for their sake and mine further down the line.

It's not boring in a sense of being boring to learn, read, or write. Ada or Java are languages that are "boring" in this sense, but which nevertheless offer far better abstractions than Go.

Go is boring in a sense that it's not innovative. Go's claim to innovation is that the feature set is tuned for new users, but that's not actually the case.