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

181–190 of 378 posts

Re: Generics enabled by default in Go tip

#181

Post by masklinn »

tptacek wrote: post #177
takeda wrote: post #152

Earlier quoted context omitted.

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…

I'm not sure I follow, because Rust is also (thankfully) fussy about integer types.

I think what they mean is utility functions (e.g. min/max here) tend to only be implemented for one type, so if you’re using an other you keep casting back and forth.

Rust is very fussy about types and some operations are bound to a single one (e.g. stdlib sequences only index with usize) but utility functions tend to either be genetic or be mass-implemented using macros (or by hand probably for f32::min and f64::min though I did not check).

Re: Generics enabled by default in Go tip

#182

Post by andy_ppp »

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.

Personally I find code with generics just as easy to read as (largely duplicated) implementations for each type. I might consider Golang again when this drops and there are things to be like about how low level it is…

Re: Generics enabled by default in Go tip

#183

Post by smcl »

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.

You’re making it sound like these are the same group of people and they’re just really fickle, whiny and impossible to please. But my memory of these older go/generics threads were that commenters were split between “I love go, I wish it had generics” and “I love go, I don’t think it needs generics”. The former have no need to comment anymore, the latter will still want to express their feelings.

Re: Generics enabled by default in Go tip

#185

Post by Zababa »

pm90 wrote: post #90
buu700 wrote: post #18

Earlier quoted context omitted.

I personally think this will be a great thing for the quality of the language (no typed higher-order functions is a massive pain point as-is), but at the same time one could argue that this is an equally massive bait-and-switch for all the developers who prefer Go's original take on "simplicity".

Go is still pretty “simple”. They didn’t introduce a while loop. Adding generics would arguably “simplify” the language even further since you would presumably throw away a lot of duplicated code.

> Go is still pretty “simple”. They didn’t introduce a while loop.

What are you talking about? There is already a while loop, it's just under a different name. I don't think reusing keywords for other purposes is an example of simplicity.

Re: Generics enabled by default in Go tip

#186

Post by erik_seaberg »

anothernewdude wrote: post #158
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.

My employer has not moved on and it’s steadily encroaching more even on strong Scala/Java teams, so I’m glad to see the worst impediments start getting fixed.

Re: Generics enabled by default in Go tip

#187

Post by smokey_circles »

Language flamewars on internet forums are... strange.

Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it?

I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful.

Use Go if you like the "clarity", stay away from it if you don't like the "verbosity".

These are both valid points, but they're subjective. Pushing it as fact is dishonest and self-serving, as well as eventually detrimental.

Re: Generics enabled by default in Go tip

#190

Post by [deleted] »

dehrmann wrote: post #161
tptacek wrote: post #148

Earlier quoted context omitted.

You would use a slice as your non-associative container, and you would write a loop over it. You just wouldn't use a linked list.

And honestly, 9 times out of 10, I'm better off rebuilding the list because vectors have lower memory overhead and the memory is contiguous. But that one time... I've also been spoiled by Java's very rich set of collections.

[deleted]
Post reply on HN