[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.