Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.carlmjohnson.net

Post reply on HN
Print view View original

231–240 of 305 posts

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

#231

Post by za3faran »

Mawr wrote: post #216
za3faran wrote: post #79

Earlier quoted context omitted.

Java now has records, record patterns, pattern matching, and switch expressions. Things that the golang author still don't seem to understand the need for (quite ironic for a language that claims it makes concurrency easy).

Is that more or less ironic than Java copying Go's goroutines and still struggling to add value types?

Java's designers have consistently mentioned the approach they're taking that Java has the last mover advantage. They cautiously see what features other languages applied, and take what gives them the highest value compared to the complexity introduced.

Java's virtual threads are already superior to golang's approach because they're working on structured concurrency from the start.

Value types are a huge proposition, but they seem to be coming along nicely. They have already baked in nullables/zero values into the design, something that is a pain in golang, and a big gotcha and source of bugs.

The interesting thing is that Java already beats golang because of its superior GCs, particularly in large programs, so it will be interesting to see what sort of performance improvements come out of value types.

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

#232

Post by earthboundkid »

vl wrote: post #124

The biggest go problem in practice is ironically omitted in both blog posts: Verbosity of error handling! There should be a shorthand for returning if last ret value is non-nil in one line. Otherwise all you code is littered with: if err != nil { return err } and it makes it four times as long and way less readable as a result. This needless verbosity really reminds me of Java. Also, go fmt is not opinionated enough!…

As a factual matter, both blog posts mention the verbosity of error handling. The second one even specifically mentions wanting Zig's try, which is shorthand for returning early if the error value is not nil.

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

#233

Post by earthboundkid »

stpedgwdgfhgdd wrote: post #27

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code. What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

I almost included a section on enums in the post, but I figured it was long enough, and I don't really have strong opinions about it. Probably a normal enum system would be better than iota, but it's not worth switching.

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

#234

Post by earthboundkid »

kubb wrote: post #4

Copilot and the like are good for Go, because you can generate all the boilerplate code they make you write. As for the success, it's obviously the minimal set of language features, conformance to established paradigms, not being very broken and being backed by Google. There's a ton of suboptimal choices in Go, but overall it can work for many applications.

Dart is backed by Google.

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

#235

Post by earthboundkid »

tail_exchange wrote: post #14

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is. Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not somethi…

The article has a link to the Wikipedia page on null titled "the billion dollar mistake."

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

#236

Post by c-cube »

wolfspaw wrote: post #28

Go has turned into an Awesome language. I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures. Now it has Generics, soft RT GC, and it might even get official Arena Allocation. I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.

It still doesn't have sum types. Maybe 10 more years and Go can catch up to SML (a language from the 1970s). That's a big weakness for a static language this millennium.

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

#237

Post by sharts »

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…

Part of that success may have to do with "Wow, Google invented this...let's use it."

Kubernetes adoption seems to be going up but does it really add value for most that adopt it? I would say, no.

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

#238

Post by pie_flavor »

Veraticus wrote: post #138
pie_flavor wrote: post #111

Earlier quoted context omitted.

There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs. Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of…

This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming. Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source proje…

    > rg BTreeMap monorepo/ --type rust --no-filename | awk NF | wc -l
    1656
You may not have ever encountered a use case for a tree map, but there is quite a wide gray area between 'computer science edge cases' and cookie-cutter CRUD apps. For example, deterministic map ordering, or sets for map keys, or fast map equality.

Funny that you mention Kubernetes. This is the tree map implementation Kubernetes depends on https://github.com/google/btree

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

#239

Post by gaganyaan »

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…

Nah mate, sorry. Go is a language already past its prime, which is laughable given how young it is, and how it was modeled on better, long-lived languages. Take a look at Google trends if you disbelieve me. There was a slight bump in interest when generics finally got pushed out, but that's died off, and Go is entering the same decline as other has-beens like Ruby. Good riddance to a language designed for people that aren't good at programming (you'll have to look up the quote yourself, I'm too lazy).

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

#240

Post by gaganyaan »

monksy wrote: post #90
softirq wrote: post #57

Earlier quoted context omitted.

> 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…

> you can learn in a day and keep in your head. I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.

Yeah, I can keep Brainfuck in my head easily. Doesn't mean I'm going to use it as anything other than a toy language.
Post reply on HN