Generic interfaces - Hacker News

Posted by Merovius 7/7/2025

58 points | 76 commentspage 2

booleandilemma 7/10/2025|

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.

eru 7/10/2025||

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

vbezhenar 7/10/2025||

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

haiku2077 7/16/2025||

> A language that would look the same today and ten years from now.

You can still write Go 1.11 code and compile it with the Go 1.24 compiler. If you specify 1.11 in your go.mod it compiles your code with the 1.11 syntax.

Traubenfuchs 7/10/2025||

“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?

exceptione 7/10/2025|

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.

eru 7/10/2025|||

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

Imagine telling everyone to be a professional and being careful not to break our program when they edit the code? Sounds like a big people problem!

Instead, we give everyone their own copy to muck around with (instead of a shared folder), and we only allow changes to be integrated into the 'master copy', if they pass automated tests.

A good manager and really motivated and professional workers can help cope with people problems. But there's a limit to their ability. So the more we can offload to technological solutions, the more 'professionalism' (for lack of a better word) we can spare for other task that aren't feasible to be solved via technology, yet.

And I agree that not all technical solutions work! You need to experiment, and make judgement calls.

exceptione 7/10/2025||

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.

eru 7/14/2025||

Python has gotten a lot better over the years. Though I'm not sure exactly which problem(s) with Python you are talking about, there are still plenty left.

guappa 7/10/2025|||

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

bravesoul2 7/10/2025||

Wait till they hear about typeclasses!

tapirl 7/10/2025|

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.

ivanjermakov 7/10/2025|

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

tapirl 7/10/2025||

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

vbezhenar 7/10/2025||

Market for simple language opened. Someone will fill it. Go failed expectations, by turning into C++.