Ten years of “Go: The good, the bad, and the meh” • Hacker News Board

Re: Ten years of “Go: The good, the bad, and the meh”

#171

Post by za3faran » Tue, Jul 18, 2023, 8:24 PM UTC

zimpenfish wrote: post #144

za3faran wrote: post #73

Earlier quoted context omitted.

golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.

> And I question this litmus test of using a junior dev anyway. As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard. [1] Sometimes literally a junior too. [2] There's a few things I think might trip up someone brand new to G…

Junior as in non-expert in the field. Using simplistic languages means optimizing for quickly pumping out code (at the expense of maintainability in the case of golang, as I've personally experienced at an employer that has one of the largest golang setups on the planet). Not to mention that golang comes with its own set of gotcha's and idiosyncrasies that need to be understood, especially in more involved programs.

There's a good middle ground that can and has been achieved by other languages.

Re: Ten years of “Go: The good, the bad, and the meh”

#172

Post by nateb2022 » Tue, Jul 18, 2023, 8:26 PM UTC

Capricorn2481 wrote: post #125

nateb2022 wrote: post #112

Earlier quoted context omitted.

Why C#? It definitely has its own niche, and is good for building userspace Windows apps and games, however beyond Windows I don't think it has neither an established presence nor ecosystem. If anything, C# attempts to be more of a Java replacement than address Go's niche. Performance-wise, C# and Go are head-to-head: https://programming-language-benchmarks.vercel.app/go-vs-csh... I also would say Go has been much mo…

C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere. There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

I would beg to differ.

On Github[0], Go currently sits at #3 for pull request volume (C# is at 10), #3 for stars (C# is at 8), #6 for pushes/commits (C# is at 10) and #6 for issues opened (C# is at 9). By each of those metrics, Go has a significantly more vibrant ecosystem than C#.

[0]: https://madnight.github.io/githut/#/pull_requests/2023/2

Re: Ten years of “Go: The good, the bad, and the meh”

#173

Post by za3faran » Tue, Jul 18, 2023, 8:28 PM UTC

tredre3 wrote: post #105

za3faran wrote: post #75

Earlier quoted context omitted.

> Working on a cross-platform project where in Go, I write code and it just builds I've worked on large golang code bases that had to build on bazel, and I had the same experience fighting it. It has nothing to do with the language. > In Java, I fight with Gradle. So gradle's issue, not Java's. See above.

> I've worked on large golang code bases that had to build on bazel, and I had the same experience fighting it. It has nothing to do with the language. So you deliberately added complexity instead of using Go's own build system and it didn't work out well and that's somehow a proof that Go's cross-compilation story isn't as great as people say?

It wasn't my call on what they did, and they had their reasons (running one of the largest golang monorepos on the planet). My point was to show that this is a build tool issue, not a language issue.

Re: Ten years of “Go: The good, the bad, and the meh”

#174

Post by soulbadguy » Tue, Jul 18, 2023, 8:29 PM UTC

softirq wrote: post #57

wk_end wrote: post #46

> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful.

And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good measure of wether or not the criticism of go were/are valid.

> Go made me truly realize how insufferable the PLT community is

Agree PLT folks can be a passionate bunch, i am not sure they are any worst to any other online community.

> and why they are so absolutely lost when it comes to creating successful languages.

Depends on who you include in the PLT group :

- C# and typescript were design by Anders Hejlsberg , arguably the most successful language designer - Scala is also pretty successful and really tied to the PLT community - Kotlin by JetBrain, Dart started with Gilan Bracha

Not to mentioned the wide range of features seen in most recent language (async-await, reactive programming for msft research) etc... etc...

The fight between pragmatic and simple language vs complex and expressive language is not happening outside the PLT, we have proponent of both ways of thinking inside the community. Not everyone in the PLT is pushing for overly complex theoretical approaches.

But more importantly, let's not forget the 1000's of engineer quietly implementing the compiler, libraries etc... that make go, or any other language possible.

Back to go, my personal gripe with go wasn't the decisions they made, but the rational given for those decisions.

Take the most famous example of not including generics. Designing a good generic type system is a very complicated task, and if the team had come out and say they didn't want generics because they didn't have the bandwidth or the know-how to do so, i wouldn't have care. But the rational given, describing generics as border line useless, or somehow too hard for the average programmer to grasp not only fly against basically 25 years of programming language history, but were just plain rediculous.

Re: Ten years of “Go: The good, the bad, and the meh”

#175

Post by o1y32 » Tue, Jul 18, 2023, 8:38 PM UTC

nateb2022 wrote: post #172

Capricorn2481 wrote: post #125

Earlier quoted context omitted.

C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere. There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

I would beg to differ. On Github[0], Go currently sits at #3 for pull request volume (C# is at 10), #3 for stars (C# is at 8), #6 for pushes/commits (C# is at 10) and #6 for issues opened (C# is at 9). By each of those metrics, Go has a significantly more vibrant ecosystem than C#. [0]: https://madnight.github.io/githut/#/pull_requests/2023/2

If you like arbitrary metrics, here is another:

https://survey.stackoverflow.co/2023/#most-popular-technolog...

Re: Ten years of “Go: The good, the bad, and the meh”

#176

Post by soulbadguy » Tue, Jul 18, 2023, 8:38 PM UTC

Veraticus wrote: post #155

z0r wrote: post #101

Earlier quoted context omitted.

Writing and reading repetitive code leads to unintentional defects. This is why for loop syntax that directly iterates through a collection is less error prone than the equivalent loop built on indexed look-ups. "Clever" code, at least when it is shorter, is often clearer than "simple" code.

I entirely disagree; defects are created by complexity, not repetition.

> defects are created by complexity, not repetition.

Any reference for this ?

I though there was a pretty strong connection between the total number of line of code and the number of bug... That's the whole point of DRY.

Re: Ten years of “Go: The good, the bad, and the meh”

#177

Post by dlisboa » Tue, Jul 18, 2023, 8:43 PM UTC

btilly wrote: post #127

wk_end wrote: post #46

> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…

Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. The Go team was populated by people who had created one of the most influential languages of all time, C. Who created the new language based on theories about how to encourage good engineering practice. Theories that they were able to test…

> Few of the critics who "knew about programming languages" have created any language that ever made it into the top 10 programming languages in the world.

I often encounter some people in programming which I think lack humility. It's fine to question dogmas and the "big heads", but one has to look at the caliber of people you're up against and maybe give them the benefit of the doubt, if only a little bit.

I certainly wouldn't read a few PLT books and lambda-the-ultimate.org and then point to Ken Thompson and Rob Pike and say "your language has no , you don't know what you're doing". These are not amateurs.

It's also doubtful they liked everything they put in, or disliked something they left out. Even Rust's creator didn't like some of the direction his language took.

If we were to ask other famous language designers they probably have a fonder feeling towards Go than people in this thread, knowing all of the hard design decisions one has to make to create an impactful language with an identity.

Re: Ten years of “Go: The good, the bad, and the meh”

#178

Post by soulbadguy » Tue, Jul 18, 2023, 8:43 PM UTC

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.

I can't think of any other less confrontational way to say/ask , but beside GO which other language have you used ?

Because the above statement is so far remove from my experiences and understand of programming that i suspect we don't we really use the same day to day tools/languages in general.

Re: Ten years of “Go: The good, the bad, and the meh”

#179

Post by Someone » Tue, Jul 18, 2023, 8:48 PM UTC

nateb2022 wrote: post #172

Capricorn2481 wrote: post #125

Earlier quoted context omitted.

C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere. There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

I would beg to differ. On Github[0], Go currently sits at #3 for pull request volume (C# is at 10), #3 for stars (C# is at 8), #6 for pushes/commits (C# is at 10) and #6 for issues opened (C# is at 9). By each of those metrics, Go has a significantly more vibrant ecosystem than C#. [0]: https://madnight.github.io/githut/#/pull_requests/2023/2

I would think that data is only about the publicly visible part of GitHub, and guess C# has relatively more activity in the dark part of GitHub.

Now, whether that would move C# over golang, I wouldn’t dare guess.

Re: Ten years of “Go: The good, the bad, and the meh”

#180

Post by SCLeo » Tue, Jul 18, 2023, 8:52 PM UTC

j1elo wrote: post #65

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I…

Honestly, I'm incredibly frustrated with this issue; it's just pure idiocy. Commenting out a part of the code and observing the effects is such a simple and useful debugging technique, yet this "feature" of Go prevents you from doing so effectively.

What's even more frustrating is that when you search for solutions, you come across two kinds of (pardon my language) completely brain-dead responses:

First, there are those who argue that unused variables/imports lead to bugs and worse performance in production, so they should always be fixed. But that's completely beside the point; I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do.

Secondly, people suggest using a dummy function like UNUSED or a blank variable _ to solve the problem. But again, these suggestions miss the mark entirely. Changing variable names or adding UNUSED calls to "disable" the rule is even worse than what we've been doing to temporarily "circumvent" the rule, which is simply commenting out the declarations, test, and undo afterwards. Not only it involves more effort, but more crucially, you might actually forgot to revert those changes and leave in unused variables.

Frankly, I believe this is just a bad design decision, and it seems like the Go team is stubbornly doubling down on this mistake due to ego.

(Sorry, I just have a very strong opinion on this topic, and I am deeply frustrated when the tools I am using think they know better than I do and are adamantly wrong.)