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

41–50 of 78 posts

Re: Generic interfaces

#41

Post by khalic »

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

“I don’t like this so let’s force every one who disagrees with me to do it my way if they want to read my stuff”. How very mature

Might release an extension just to spite him

Re: Generic interfaces

#42

Post by vbezhenar »

eru wrote: post #33
booleandilemma wrote: post #29

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

> When I first learned about Go I thought the idea was to have a simple C-like language with a frozen feature set. C is a C-like language with a mostly frozen feature set. (If you want something less insane than C, there's also Pascal.)

C is not frozen.

C11 added generics, multi-threading, unicode support, static assertions. It broken compatibility with earlier versions by removing `gets` function.

C23 added `nullptr`, very fundamental change. typeof operator. auto keyword for type inference. Lots of breaking changes by introducing new keywords. Another breaking change is empty brackets `()` now mean as function taking no arguments.

So lots of new features and breaking changes with every new iteration. Thankfully, compilers support sane standards, so you can just use `-ansi` and live happy life, I guess...

Re: Generic interfaces

#43

Post by Merovius »

khalic wrote: post #41
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 don’t like this so let’s force every one who disagrees with me to do it my way if they want to read my stuff”. How very mature Might release an extension just to spite him

https://chromewebstore.google.com/detail/go-docs-syntax-high...

Re: Generic interfaces

#44

Post by alkonaut »

aranw wrote: post #26
alkonaut wrote: post #24

Earlier quoted context omitted.

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

Yes. And there should be studies that show that the number of people who are hampered by syntax highlighting is probably so vanishingly small sompared to those that are either helped or not helped (unhelped, but not hampered)

Syntax highlighting studies usually don't report on whether some subjects perform worse with syntax highlighting - usually only that they as a group perform better. But even with that evidence, it should be obvious that syntax highlighting should be either on for everyone, or on initially and off as an option for the rare individual.

https://ppig.org/files/2015-PPIG-26th-Sarkar1.pdf

Re: Generic interfaces

#45

Post by yawboakye »

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.

one wonders why colors exists after all. why, we should know all about vegetation, streams, living, and non-living organisms so that their chromatic attributes are very unnecessary. monochrome for the win! i propose dark gray btw /s

on a more serious note: somehow nature choose to let us see colors, and this sense has been immensely useful to our existence and pleasure. maybe go could learn a thing or two from nature?

Re: Generic interfaces

#46

Post by henry700 »

>There is an idea that is not obvious until you hear about it for the first time: as interfaces are types themselves, they too can have type parameters

Not obvious???? Go language designers and programmers are living in another world

Re: Generic interfaces

#47

Post by exceptione »

eru wrote: post #34
exceptione wrote: post #18

Earlier quoted context omitted.

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.

> 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. Nah, it was just the wrong solution. People problems are basically intractable in the grand scheme of things. Whenever you can turn a people problem into a technical problem, that's an opportunity for progress.…

I agree it was the wrong solution. The problem is that Go is quite popular and lots of code has been written in a language that cannot be fixed. And that is also a people problem, because living daily with a programming language feels like a marriage.

People keep fixing the unfix-able rather than moving on. I see the same happening with Python.

Re: Generic interfaces

#48

Post by nadavwr »

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

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 practically zero complexity overhead due to integration -- without any true plugin architecture. There are limits to what can be accomplished this way, but it is surprisingly powerful and I can see why a community might gravitate to his views. Unfortunately he takes this minimalist approach too far when it comes to languages IMO -- a language with no coproducts in 2025 is either a niche language or unnecessarily underpowered (how they do error handling is atrocious). Over the last decade Go went from the former to the latter.

Re: Generic interfaces

#49

Post by gabrielgio »

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 anything beyond the stdlib will need to handle generics. They aren't widely used but quite useful when needed, which I think it is sweet-spot for generics.

I don't share the same animosity against generics. I like the recent language addition to the stdlib and am also waiting for them to add some sugar to reduce the boilerplate in error handling.

> 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

Re: Generic interfaces

#50

Post by klabb3 »

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. The argument was whether the complexity was worth it and compile time speed could remain so fast. Even the improved expressivity isn’t obviously good (famously the removal of goto was good because it reduced expressivity).

Just stating the arguments, I still haven’t made up my mind whether these limited generics was the right call. Leaning yes, but it’s important to be humble. It takes a lot of time to evaluate second order effects.

> Especially in the era of AI assistants

As an aside, I really don’t appreciate this argument without extremely strong merits, which we can’t possibly have. Not everyone is using AI assistants, nor do people use it in the same way. But most importantly it changes very little since code is not bottlenecked by writing anyway. Code is read more often than written, and still needs to be reviewed, understood and maintained.

Post reply on HN