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

Generic interfaces

go.dev

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Generic interfaces

#51

Post by syklemil »

ntstr wrote: post #19
ISNIT wrote: post #15

Sort of wild that the Go blog doesn't have Go syntax highlighting...

It makes more sense if you know about Rob Pike: https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B... >Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods ( http://en.wikipedia.org/wiki/Cuisenaire_rods ). I grew up and today I use monochromatic numerals. The language creator really hates it (and most modern editor tooling).

Which also makes more sense if you take into consideration that he has a form of colour blindness: https://commandcenter.blogspot.com/2020/09/color-blindness-i...

Ultimately he's fine with _some_ syntax highlighting, especially the kind that uses whitespace to highlight parts of the syntax, as evidenced by the existence of `go fmt`. He just hasn't taken into consideration that colour is just one typographical tool among many, including the use of whitespace, as well as italics, bold, size, typeface, etc. Switching inks has been somewhat tedious in printing, but these days most publications seem to support it just fine, and obsessive note-takers also use various pens and highlighters in different colours. For the rest of us it's mostly about the toil of switching pens that's holding us back I think, rather than some real preference for monochromatic notes. We generally have eyes that can discern colours and brains that can process that signal in parallel to other stuff, which along with our innate selective attention means we can filter out the background or have our attention drawn to stuff like red lights. Intentionally not using that built-in hardware feature is ultimately just making stuff harder on oneself with no particular benefit.

There's also some google groups quote from him about iterators which is also pretty funny given how modern Go uses them, but I don't have the link at hand. Several google groups quotes from the original language creators (not just Pike) tell an unfortunate story about how the language came to be the way it is.

Re: Generic interfaces

#52

Post by syklemil »

gabrielgio wrote: post #49
ricardobeat wrote: post #39

Preaching to the choir here, but this is why a lot of the Go community was against generics. Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little, while the upside of avoiding all this complexity is unmeasurable.

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful. This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly…

>> Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little

> Yeah, let's design languages based on the capabilities of code assistance /s

I mean, that _is_ essentially the Go team's take these days, c.f. their previous blog post about error handling: https://go.dev/blog/error-syntax

> Writing repeated error checks can be tedious, but today’s IDEs provide powerful, even LLM-assisted code completion. Writing basic error checks is straightforward for these tools. The verbosity is most obvious when reading code, but tools might help here as well; for instance an IDE with a Go language setting could provide a toggle switch to hide error handling code.

Personally I expect that getting an LLM to write error handling and then have the IDE hide it sounds like a recipe for surprises, but I guess things work out differently if the goal is to have hordes of the cheapest possible juniors kitted out with tools that let them produce the most amount of code per dollar.

Re: Generic interfaces

#53

Post by ncruces »

syklemil wrote: post #52
gabrielgio wrote: post #49

Earlier quoted context omitted.

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful. This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly…

>> Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little > Yeah, let's design languages based on the capabilities of code assistance /s I mean, that _is_ essentially the Go team's take these days, c.f. their previous blog post about error handling: https://go.dev/blog/error-syntax > Writing repeated error checks can be tedious, but today’s IDEs provide p…

It's one thing to say that:

- an LLM can help you write a boilerplate `if (err != nil) { return fmt.Errorf(...) }` that actually matches the conventions for code base you're in;

- your IDE can "hide" those additional lines of code to reduce cognitive load while reading code;

- it's actually useful that those "hidden" lines are there when you're debugging and want a place to add a breakpoint, or some additional logging, etc.

This is very different from saying you should have an LLM auto generate half a dozen indentical copies of sync.Map, container.List, my.Set or whatever.Tree based on the types you want to put in your container.

I'm actually fine with an LLM as a more powerful auto complete, that generates half a dozen lines of code at a time (or slightly tweaks code I paste) based on context.

I would have a problem with a LLM generating thousands of lines of code based on a prompt "this, but for ints" and then it's a fork of the original, with god knows how many subtle details lost, and a duplicated maintenance burden going forward.

Re: Generic interfaces

#54

Post by gabrielgio »

syklemil wrote: post #52
gabrielgio wrote: post #49

Earlier quoted context omitted.

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful. This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly…

>> Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little > Yeah, let's design languages based on the capabilities of code assistance /s I mean, that _is_ essentially the Go team's take these days, c.f. their previous blog post about error handling: https://go.dev/blog/error-syntax > Writing repeated error checks can be tedious, but today’s IDEs provide p…

> that _is_ essentially the Go team's take these days

It is not "essentially their take". It is one of the point (a weak one for what my opinion is worth) but far from their main point. Their main point from the text is the same point they always make in these cases:

> Coming up with a new syntax idea for error handling is cheap; hence the proliferation of a multitude of proposals from the community. Coming up with a good solution that holds up to scrutiny: not so much.

> the goal is to have hordes of the cheapest possible juniors kitted out with tools that let them produce the most amount of code per dollar

I share the same concern here. I don't have a solid opinion on how that will turn out but I'm not too optimistic.

Re: Generic interfaces

#55

Post by oasisaimlessly »

nadavwr wrote: post #48
ntstr wrote: post #19

Earlier quoted context omitted.

It makes more sense if you know about Rob Pike: https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B... >Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods ( http://en.wikipedia.org/wiki/Cuisenaire_rods ). I grew up and today I use monochromatic numerals. The language creator really hates it (and most modern editor tooling).

I'm a fan of Rob Pike, but not of Go. Rob Pike contributed a lot of thought to editor tooling through the years, albeit not in the direction the industry seems to be going -- for example, Sam and Acme are two editors he developed. Acme UI design is inspired by Oberon and is based on tiling, but 3rd party tooling integration is entirely different and leverages Plan9 concepts to enable a whole lot of extensibility with…

To save others a google: coproducts = sum types AKA tagged unions.

Re: Generic interfaces

#56

Post by tapirl »

gabrielgio wrote: post #49
ricardobeat wrote: post #39

Preaching to the choir here, but this is why a lot of the Go community was against generics. Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little, while the upside of avoiding all this complexity is unmeasurable.

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful. This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly…

> Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster.

No, this is not true for Go, at least for the current Go generics.

At runtime, Go generics can't be faster than generated repetitive code. Often, generic code is a little slower. Because sometimes values of type parameters are treated as interface values by the Go compiler, even if they are not.

> Handling interface{} was just painful.

Go generics are often helpless for this. Most use cases of interface{} are for reflection purpose and can't be re-implemented by Go generics. Some non-reflection use cases can't be also re-implemented by Go generics, because Go generics don't support type unions.

Re: Generic interfaces

#57

Post by ricardobeat »

klabb3 wrote: post #50
ricardobeat wrote: post #39

Preaching to the choir here, but this is why a lot of the Go community was against generics. Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little, while the upside of avoiding all this complexity is unmeasurable.

> the downside of writing out explicit types and repetition matters very little That’s not the main reason. You can have a library by author X that provides a container type Heap[T] and you can use it with your type T which is unknown by X and requires no coordination. If the proto-generic maps and slices did not exist in Go it would not be a useful language at all. This pain point was glaring in Sort and Heap in std…

As far as I've seen, a heap implementation using generics is not any shorter or simpler than the old `heap.Interface` - what it gained is reusability.

> Code is read more often than written, and still needs to be reviewed, understood and maintained.

Which takes us back to the points above. AI is really good at generating repetitive patterns, like plain types, or code that implements a certain interface. If you reduce the cost of creating the verbose code [at write time] we can all enjoy the benefit of reduced complexity [at read time] without resorting to generics.

Also not saying this as an absolute truth, it is more nuanced than that for sure. But in the big picture, generics reduces the amount of code you have to write, at the cost of increased layers of abstraction, and steering away from the simplicity that make Go popular in the first place. Overall I'm not convinced it was a net positive, yet.

Re: Generic interfaces

#58

Post by tapirl »

ivanjermakov wrote: post #35

Remember when Go proposed as a simple language? What a shitshow. Seems like Go's designers didn't know about interfaces, generics, and iterators when decided to make a language...

It was also promoted as a language that prioritizes explicitness. But just look at the changes made in Go 1.22 (3-clause for-loop semantic change, [1]) and 1.23 (iterators, [2]). Magic implicitness was introduced in the two versions.

Even worse, it was also promoted to keep backboard-compatibility seriously. But Go 1.22 broke the backward-compatibility so badly ([3] [1]). Despite this, the Go 1.22 release notes still claims "As always, the release maintains the Go 1 promise of compatibility".

[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

[2]: https://go101.org/blog/2025-03-15-some-facts-about-iterators...

[3]: https://go101.org/bugs/go-build-directive-not-work.html

And the change makers even have no interests to fix the problems caused by the changes:

* https://github.com/golang/go/issues/66070#issuecomment-19816...

* https://github.com/golang/go/issues/71830

* https://github.com/spq/pkappa2/issues/238

* https://github.com/golang/go/issues/66388

* https://github.com/golang/go/issues/71685

Re: Generic interfaces

#59

Post by tapirl »

bravesoul2 wrote: post #17

Wait till they hear about typeclasses!

If Go generics support typeclasses, things will be much better now. At least custom generics and built-in generics will be unified harmoniously. Now, the manners of type argument passing with the built-in `new` and `make` function and custom generic functions are different. The inconsistency increases the load of cognition burden in Go programming.

It is pity that Go generics designer never expressed the intention to unify custom generics and built-in generics.

Re: Generic interfaces

#60

Post by [deleted] »

tapirl wrote: post #56
gabrielgio wrote: post #49

Earlier quoted context omitted.

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful. This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly…

> Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. No, this is not true for Go, at least for the current Go generics. At runtime, Go generics can't be faster than generated repetitive code. Often, generic code is a little slower. Because sometimes values of type parameters are treated as interface values by th…

[deleted]
Post reply on HN