[jordz]

I don’t think it’s fair to say they ignored advances in modern programming languages. There are opinionated reasons for the omission of generics and they do make sense in the overall architecture of the language. At the end of the day it’s about trade offs and ultimately my opinion is that, having written a lot of both C# and Go, I can see the pros and cons of feature sets. Its about choice of tool for the solution in mind. I’m happy with that.

[chisleu]

Absolutely! The "advances" were design decisions that go chose not to use. The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages. They had good reasons for choosing to go another way that makes sense for their language.

The end result is, in my humble opinion, a very stable language that is very high performance, and is highly maintainable. It's not perfect. It's not great for every use. Java does some things better. C does some things better, etc... It just fills a niche that was unfilled in an opinionated manor.

[sarchertech]

> The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages.

Chalking everything missing from go up to "the designers know what they are doing--every omission was on purpose", ignores the way humans design things. We are really good at post hoc rationalization.

Bob: "Why did you draw the woman in tall grass?"

Alice: "To allow the viewer to engage with the piece by forcing them to use their imagination to visualize the hidden area."

Bob: "Are you sure it's not because you don't like drawing hands and feet?"

[frankietwenty9]

At the same time critiquing without understanding the problem the engineer was trying to solve is equally easy.

Go is far from perfect, I just don't agree that lumping things in a good/bad pile is very insightful.

Engineering is all about making compromises. It's unsurprising that you'll meet everyones use cases that it's not designed for. The article would have provided additional value if it explored alternatives to the bad, and the disadvantages that come with them.

[sinatra]

They are talking about things like generics. Considering the years it took for a team of people to build Go, I think it’s fair to assume they didn’t just forget about generics and that it was an intentional decision.

[michaelcampbell]

Ignore != forget; let's not drag this tortured semantic armchair quarterbacking any further than it already has been.

[collinf]

I think one thing that people get caught up in with Go as well is... well it's stupid easy to learn and work with.

I work for a giant enterprise company and the range of programming talent that we have is incredible. I know some people that couldn't code there way out of fizbuzz. Unfortunately, getting these folks onboard to learn the functional abstractions doesn't always sell (especially to the biz folks).

One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.

My 2 cents in the bottomless well of programming language opinions.

[__sr__]

> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.

And then what? They find themselves duplicating the same code again and again because Go doesn’t provide good abstractions to reuse code. Or that they write a ton of code to do what could be achieved in a few lines in a reasonable language.

You learn the language in a week because there is not a lot to learn. Shell scripting is simple to learn as well, but nobody is building anything beyond short scripts using it.

An ideal language should allow the user to be a productive after a short time, but should have have enough power for advanced users as well.

One of the things I hate the most about Go is that source code generation is considered an acceptable solution to many problems. Perhaps I should go back to C — the preprocessor can be used to generate code as well as anything. In fact, the predecessor to C++ was a preprocessor used to generate C code that simulated C++ like behaviour.

[flavio81]

>They find themselves duplicating the same code again and again because Go doesn’t provide good abstractions to reuse code. Or that they write a ton of code to do what could be achieved in a few lines in a reasonable language.

This.

>You learn the language in a week because there is not a lot to learn.

Exactly. For example, Brainfuck is even simpler and easier than go. It also produces even worse, unmaintainable, horrible code.

[stouset]

> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.

This ranks just about at the bottom for any language I care to work with.

"Learning a language" is more than just about being able to write syntactically-correct code. It's about understanding effective design patterns, idioms, the standard library, common pitfalls, writing maintainable code, and so on.

Learning the syntax comprises less than 5% of that effort, and optimizing for that step—particularly at the expense of the other steps—is ill-advised. And in my opinion, go has done precisely this by having tons of sharp edges: nil interface values, race conditions with channels, supposed-"meaningful" zero values, implicit interface implementation, etc. are all sharp edges I've personally run into that have caused bugs in production.

[dragonwriter]

> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.

IME, that's basically the case with any language with suitable libraries in the application domain and that doesn't have radically unfamiliar syntax or programming paradigm, so this rings as praise for it being neither especially novel nor deficient in library support for it's target uses.

[flavio81]

> The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages. They had good reasons for choosing to go another way that makes sense for their language.

Yes, for using monkey coders more effectively.

>and is highly maintainable

No. Lack of exception handling and generics really hurt maintainability a lot. Not to mention that package management is still full of wrongs.

[__sr__]

A lot of the decisions were made because:

1. It complicates the compiler. 2. It slows down the compilation. 3. We didn’t think about it in the beginning, and can’t add it now without making non backwards compatible changes. 4. It makes the language harder to learn. 5. We don’t use this feature a lot.

I didn’t invent these reasons — search for why doesn’t golang have <insert-feature> — and you will eventually come across one or the other as a reason mentioned by one of the core members.

[stouset]

I get that you're just the messenger, but almost every one of these arguments makes my blood boil.

1. So what? The whole point of writing a high-level language is to pay the cost of low-level burdens once so that application developers don't have to pay them repeatedly.

3. This makes me treasure even more greatly the Rust core team's forethought when releasing Rust 1.0, in ensuring they hadn't walled themselves into any easily-avoidable corners before stabilizing the language. Such an approach has repeatedly paid dividends.

4. Optimizing for a person's first week of using a language at the expense of their next ten years is borderline indefensible.

5. This last one pretty much boils down the entire problem for me. Go is designed to solve problems Google has that most of us don't. It's also designed to solve them in a way that makes the most sense to Google (e.g., dependency management is irrelevant if you have a monorepo).

[__sr__]

I totally agree, in case it wasn’t clear. Go, like many others, was designed by people who thought the users of the language are not as smart as themselves. They seem to have forgotten that after writing a few thousand lines, even a novice can become a power user and start demanding more of the language.

[jrs95]

Unfortunately this meme will never die. The good news is I’ll be getting shit done while people who go on about this crap will just blog about Rust or monads or something.

[jeremiep]

Yet here you are going on about this crap instead of getting shit done.

The people who care about improving their tools and knowledge will almost certainly end up way more productive than those who don't.

There's a thing called meta-ignorance; you don't know what you don't know, so how can you tell you're really getting stuff done optimally?

[jrs95]

Improving your tools != making the same stupid argument people have been making for a decade as if it hadn’t happened before. I actually agree that there are improvements to be made to Go; generics and dependency management being 2 that look like they’ll probably be resolved soon. That’s not that the same as this crap about “it ignores advances in programming!” or “it’s a failure because it’s not a systems language like they said it would be when they announced it.” or “Google made it because they think their programmers are too stupid to write Haskell.”

Improving tools is complicated and involves a lot of trade offs. It’s not just “omg it doesn’t even have generics what a shit language.”