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

21–30 of 78 posts

Re: Generic interfaces

#21

Post by guappa »

exceptione wrote: post #18
Traubenfuchs wrote: post #12

“Maybe generics like in java and C# actually made sense after all.“ Welcome to civilization, golang. Were there ever any language developers with more hybris?

I think of it less as hybris and more of a (failed) experiment. It was deliberately built as a 'stupid' language for fresh undergrads, lacking design experience. It is a technical solution for a people problem. It is better to guide and to mentor people in designing the right abstractions. What we should learn from this experiment is that this is the wrong approach.

To me it's very useful. Whenever someone tells them go is their favourite language I know they can't be trusted.

Re: Generic interfaces

#22

Post by aprilthird2021 »

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

This is hilarious to me

Re: Generic interfaces

#23

Post by Cthulhu_ »

asim wrote: post #7

If I'm being honest, the magic of Go was lost when generics were introduced. It now feels akin to Java, which I guess was inevitable and for anyone to really take it seriously maybe it needed to get here. But I am not a fan of generics. While that level of abstraction and composability is clever, it also lends itself to more complexity and systems that can be harder to concretely understand. Just an opinion that I kn…

The difference with Java is that in Java, generics are everywhere and they make up half the Java spec - I bookmarked a page ages ago (from a HN comment) that highlights it, see [0], and that's just one page.

With Go, at least initially, it was an addition, not a core aspect of it - any code written in Go before generics will still work. Granted, I only have one real project but I never had a use case for generics - the built-in generic structures (map and arrays/slices) were enough for me. Maybe when you have code that works with the `interface{}` a lot (e.g. unknown JSON data) you'll have a use case for it.

[0] https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParam...

Re: Generic interfaces

#24

Post by alkonaut »

Cthulhu_ wrote: post #20
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).

It's definitely weird in this day and age, but in the Go code examples... I don't miss it. Paraphrasing, but if you need syntax highlighting to comprehend code, maybe your code is too complicated.

How does that matter, if it's more _easily_ comprehended (faster, with less effort, with fewer mistakes in comprehension) with the highlighting, for any level of complexity?

Not choosing to use syntax highlighting is just wrong on every level. It has exactly zero drawbacks.

Re: Generic interfaces

#25

Post by lordofgibbons »

Cthulhu_ wrote: post #20
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).

It's definitely weird in this day and age, but in the Go code examples... I don't miss it. Paraphrasing, but if you need syntax highlighting to comprehend code, maybe your code is too complicated.

That's just suffering for suffering sake with no fathomable benefit. Why not reduce cognitive overhead if you can get it for free?

Re: Generic interfaces

#26

Post by aranw »

alkonaut wrote: post #24
Cthulhu_ wrote: post #20

Earlier quoted context omitted.

It's definitely weird in this day and age, but in the Go code examples... I don't miss it. Paraphrasing, but if you need syntax highlighting to comprehend code, maybe your code is too complicated.

How does that matter, if it's more _easily_ comprehended (faster, with less effort, with fewer mistakes in comprehension) with the highlighting, for any level of complexity? Not choosing to use syntax highlighting is just wrong on every level. It has exactly zero drawbacks.

> if it's more _easily_ comprehended (faster, with less effort, with fewer mistakes in comprehension) with the highlighting

But this is completely relevant to the person reading. It may be for you easier with highlighting but someone else it may not be

Re: Generic interfaces

#27

Post by Merovius »

lenkite wrote: post #14

I find C++ templates simpler than Go generics. With C++, you can at-least get to a design solution. With Go generics: oops this is not possible, oops that is not possible - all because of strange language limitations. Go's Generics are a crippled implementation - they don't really deserve the feature title of 'generics'. (Its like saying you support regex, but don't support groups and repeat operators and you can onl…

I don't disagree that Go's generics are pretty limited. But I find it a strange complaint, when contrasted with C++ templates. Which, as I understand, are literally not part of the type system and thus there seems to be a far stronger case, that they can not be called generics.

The main difference between Go's generics and C++ templates (and where some of the restrictions come from) is that Go insists that you can type-check both the body of a generic function and the call to it, without one having to know about the other. My understanding is, that with C++ templates (even including concepts), the type checking can only happen at the call-site, because you need to know the actual type arguments used, regardless of what the constraints might say.

And this decision leads to most of the complaints I've heard about C++ generics. The long compile times, the verbose error messages and the hard to debug type-errors.

So, if you prefer C++ templates, that's fair enough. But the limitations are there to address complaints many other people had about C++ templates specifically. And that seems a reasonable decision to me, as well.

Re: Generic interfaces

#28

Post by Merovius »

Cthulhu_ wrote: post #23
asim wrote: post #7

If I'm being honest, the magic of Go was lost when generics were introduced. It now feels akin to Java, which I guess was inevitable and for anyone to really take it seriously maybe it needed to get here. But I am not a fan of generics. While that level of abstraction and composability is clever, it also lends itself to more complexity and systems that can be harder to concretely understand. Just an opinion that I kn…

The difference with Java is that in Java, generics are everywhere and they make up half the Java spec - I bookmarked a page ages ago (from a HN comment) that highlights it, see [0], and that's just one page. With Go, at least initially, it was an addition, not a core aspect of it - any code written in Go before generics will still work. Granted, I only have one real project but I never had a use case for generics - t…

> Maybe when you have code that works with the `interface{}` a lot (e.g. unknown JSON data) you'll have a use case for it.

I think in those cases, generics are specifically kind of pointless. Because you will inherently need to use `reflect` anyways. Generics are only helpful if you do know things about your types.

Generics are most useful for people who write special-purpose data structures. And hence for people who need such special-purpose data structures but don't want to implement them themself. The prototypical example is a lock-free map, which you only need, if you really need to solve performance problems and which specific kind of lock-free map you need depends very heavily on your workload. `sync.Map` is famously only really useful for mostly write-once caches, because that's what its optimized for.

The vast majority of people don't need such special-purpose data structures and can get by just fine with a `map` and a mutex. But Go has reach the level of adoption, where it can only really grow further, if it can also address the kinds of use-cases which do need something more specific.

Re: Generic interfaces

#29

Post by booleandilemma »

When I first learned about Go I thought the idea was to have a simple C-like language with a frozen feature set. A language that would look the same today and ten years from now. And I thought that boringness was a wonderful feature, actually.

If they're going to be adding features to the language, albeit at a slower pace than Java/C#, what's the point really? On a long enough timeline Go is going to be indistinguishable from these more feature-rich languages.

Re: Generic interfaces

#30

Post by hardwaresofton »

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

Imagine the brain cycles rob pike is wasting. Good on him for having so many to spare
Post reply on HN