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

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

151–160 of 378 posts

Re: Generics enabled by default in Go tip

#151

Post by masklinn »

brundolf wrote: post #43

I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to p…

> How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code?

They’re special-cased in the compiler, with bespoke implementations.

Re: Generics enabled by default in Go tip

#152

Post by takeda »

tptacek wrote: post #146
takeda wrote: post #139

Earlier quoted context omitted.

I used code from: https://endler.dev/2017/go-vs-rust/ good point, I overlooked that. Anyway in Go (ironically because of lack of generics) if you use any numeric type other than int, int64, float64 you will be in the word of hurt. Rust doesn't have that issue. So in practice you will likely use int, and I suppose you can add an assertion. BTW: I only see that it would remove 3 lines though, where are the other 3?

I don't follow. I use unsigned ints in Go all the time. I've never been in a world of hurt with them. Mandatory explicit integer conversions (and the way Go consts work) are something Go gets right.

Ok, so you like that. I myself really hated when I used float32 and had to do this when I was doing calculations:

    result = (float32)Max((float64)a, (float64)b)
I ended up switching the type to float64, and wonder why they even offer float32 if it's practically unusable. I had similar experience when I needed to use int8 or int16 etc.

An alternative was to make own version of Max/Min and other math functions, but this is what generics would solve.

Re: Generics enabled by default in Go tip

#153

Post by danellis »

Taek wrote: post #21
puddingforears wrote: post #17

Earlier quoted context omitted.

How would you write a singly linked list who’s contents are arbitrary? What if you were to map a function over it? Say you want to use this data structure with third-party objects? How do you do that right now?

Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.

> Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be.

That's pretty laughable considering the language designers included type-parameterized collections in the language. Apparently they recognized the need for them; they just didn't think you were smart enough to make your own. After all, Go was explicitly designed for programmers who are, in the words of its creator, "not capable of understanding a brilliant language".

Re: Generics enabled by default in Go tip

#154

Post by xh-dude »

sterlind wrote: post #74
jshen wrote: post #45

Earlier quoted context omitted.

And it would have been far harder to read for those new to the generic code base. Complex abstractions make people feel smart, they rarely make code easier to understand or maintain.

so as an example, I've used priority queues a lot. you need them for Dijkstra.. apparently golang has a heap package which lets you push and pop `interface{}`. sure you can cast, and I guess people have to, but why couldn't Go just call `interface{}` object or any? the awkwardness of the convention suggests an unwillingness to accept failure.

Parametric polymorphism is a better fit for container types IMHO. There are some interesting notes here…

In Go prior to generics, interface{} is an escape hatch less frequently needed but not necessarily much safer than void*. Post generics, interface{} is suddenly more useful and will be aliased by ‘any’.

The way the std lib heap works in Go, an implementation doesn’t have to mention interface{}. Using the Go std lib solution is about satisfying a few interfaces, defining some methods for sorting and swapping over the element type. The use of interface{} is internal.

Go’s generics solution is going to have type constraints, which I think will be very familiar to some and probably new to others … So, the Go generics PQ should still require some constraints on elements, not ’any’thing will work. I’ve really enjoyed constraints in languages and it’s not quite natural in C++/Java, but Go’s interfaces already do some ‘constraint’ work conceptually and can be used as constraints in Go’s generics syntax. I’m interested to see how this plays out.

Re: Generics enabled by default in Go tip

#155

Post by [deleted] »

dehrmann wrote: post #120
tptacek wrote: post #23

Earlier quoted context omitted.

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

> You wouldn't As someone who hasn't used Go, what would I do, then? The question about a generic data structure was very practical, your response was philosophical, and I still need a linked list.

[deleted]

Re: Generics enabled by default in Go tip

#156

Post by anothernewdude »

silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

No generics, and lack of error handling are why I bounced off Go.

Can I write a generic data structure? No. You have to cast from interface{}.

Java 1.4.2 is dead, and rightly so.

And manual error checking? No. Get that garbage out of my control flow. I'm not going to a language that has worse error handling than C. At least in C you can factor it out.

Re: Generics enabled by default in Go tip

#157

Post by anothernewdude »

theshrike79 wrote: post #61
reissbaker wrote: post #52

Earlier quoted context omitted.

While it's true that some find it liberating, a large number don't — personally, I've written a fair amount of production Go code and found it unnecessarily verbose and repetitive in ways that generics would've helped. I imagine some of this is based on problem domain; if you're writing a web application for example, maybe you don't really need generics much. After all, how often do you need a function that logs in a…

You say "verbose and repetitive", I say "easy to read without any surprises". The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.

You're right that a templating language would reduce the code and make it easier to read.

Re: Generics enabled by default in Go tip

#158

Post by anothernewdude »

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

The people who cared about Go not having generics (myself included) moved on. The time for a well designed language with Generics was five years ago.

The only people who care about Go now are the ones who convinced themselves that casting from empty interfaces was okay.

Re: Generics enabled by default in Go tip

#159

Post by mseepgood »

pkulak wrote: post #150
lokedhs wrote: post #73

Earlier quoted context omitted.

Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I was exposed to it. I was very negative towards generics and had similar arguments as you. It didn't take long before I changed my mind. I'd never want to write Java without generics again. I'm not saying you're going to have the same experience, but I would su…

Does Go generics have type erasure? If not, OP can expect and even better journey.

No, they don't have type erasure.

Re: Generics enabled by default in Go tip

#160

Post by kbenson »

silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

Either a language changes to keep interest up and bring in a new audience, or it's left behind by advances to and the status quo (and what's considered a minimum set of features) and stagnates.

Just look at Perl. Stuff written 20 years ago is likely to work without change on the newest release more often than not. For certain work contexts, like system utilities and long life core programs, this can be amazingly useful.

And all it will cost you is the slow decay of your community until eventually they're almost all gone, and nobody releases supported libraries for you anymore, and there's not even enough community left to provide community support for many new services and technologies.

If you stick around one thing long enough you're destined to be disappointed one way or the other.

Post reply on HN