Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain.

However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

View on HN

About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a correct view? We'll see. Honestly I'm starting to appreciate that. They may have a good point.

How is code with generics more complex than without it?

They're talking about the compiler and the language spec not Go code.

That's not how I interpret parent's comment.

For example the C++ templates rules are themselves a turing-complete language. If by generics you meant some really basic features, I think you can do pretty well with interfaces. They're already in the language. If by generics you meant the full-package, i think you could end up with something pretty complex all the time.

Most generic implementations are not Turing-complete, and looking at C++, this doesn't sound like a particularly tempting proposition.

And while I'm not particularly familiar with Go, I don't see how you can get a feature set equivalent to a simple implementation like Java's out of Go interfaces ("you can just cast" is not a good answer).

I'm probably missing the use case. What is the problem that you are thinking of, you can't solve with a Go interface?

Say, a generic container.

> all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go

This is what Java designers thought as well. See where this has led them.

Without generics, you can never write a type safe datastructure. I can't imagine the hubris that thinks the language already contains all of the datastructures it needs.

This isn't true. You can write a type safe data structure. It is simply for one type; you can't share it. That inability to share is the part that generics fixes, but saying you can't write type safe structures is inaccurate.

>I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

The response I've overwhelmingly observed from qualified voices isn't "boo generics!" but "generics are terribly difficult to get right, and we want to know more about Go's niche before making any design decisions in that realm".

I suspect you're reading a lot of drivel from web programmers who discovered net/http last Thursday. It's hard not to be frustrated with the internet, I concede...

A huge variety of other languages have successfully implemented generics. The Go team seems to be looking for some mythical ideal solution with no tradeoffs, and will therefore never do it.

>A huge variety of other languages have successfully implemented generics

Completely irrelevant; the argument isn't "generics are hard [full stop]". The argument is "generics are hard" AND "we don't know Go's niche well enough to commit to any specific approach".

But how can they not know that, after so many years?

You'd have to ask them, but I suppose it takes years to carve out a niche.

What I can say is that I recently interviewed a Google engineer who was conducting a survey of Go's usage, so it seems they're at least studying the question.

> However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

Where the hell did you get that from?

https://news.ycombinator.com/item?id=9622417

Reply on news.ycombinator.com