Generics enabled by default in Go tip

Post by bmn__ » Sat, Aug 21, 2021, 6:13 AM UTC

theshrike79 wrote: post #68

aptenoforst wrote: post #56

Earlier quoted context omitted.

How is a generic data structure a COMPLEX ABSTRACTION?

If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions. But some people have a tendency to play code golf with their codebases. I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th. Th…

Post by takeda » Sat, Aug 21, 2021, 6:16 AM UTC

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…

Post by dmitriid » Sat, Aug 21, 2021, 6:19 AM UTC

jrockway wrote: post #109

dmitriid wrote: post #77

Earlier quoted context omitted.

> if you're writing a web application for example, maybe you don't really need generics much All our microservices return a { result: ... } or a { result: ..., nextPageToken } We would definitely benefit from generic SingleResult and PagedResult . Instead, you copy-paste the same definitions over, and over, and over, and over again for every call.

I think I see what you're doing. Right now, each result type implements NextPager, which returns information about how to fetch the next page. You client can implement a utility like FetchNextPage: type NextPager interface { NextPage() PageSpec } func (c *Client) FetchNextPage(ctx context.Context, current NextPager) (interface{}, error) { ... } Then for each type of paged object, you write: func (c *FooClient) FetchN…

Post by Fire-Dragon-DoL » Sat, Aug 21, 2021, 6:21 AM UTC

brundolf wrote: post #127

Fire-Dragon-DoL wrote: post #125

Earlier quoted context omitted.

Of course, but remember that `len` has constant return type, while in case of slices you'd have a return type that's different on the input slice

I see. I guess I assumed that the category of special "privileged functions" would have their powers extend to cover stuff like that (I haven't used Go, I'm just going off of what I've read) I'm very intrigued by the no-generics idea, so I'm prodding at what might've made it workable enough that this reversal wouldn't be necessary :)

Post by takeda » Sat, Aug 21, 2021, 6:24 AM UTC

bopbeepboop wrote: post #117

takeda wrote: post #107

Earlier quoted context omitted.

I think readability has multiple dimensions, and it really depends what you are looking for. For example here's a code in Go to look for a Prime: func IsPrime(n int) bool { if n It's readable as it is simple to understand what each line does. Here for example is a code that does the same thing in Rust: fn is_prime(n: u64) -> bool { match n { 0...1 => false, _ => !(2..n).any(|d| n % d == 0), } } It's might seem more c…

You changed function signatures from int->bool to uint->bool, which changes how long the functions are. That seems unfair when comparing: Removing negatives from the Go implementation removes 6 out of 16 lines, bring it from 3x Rust to 2x Rust in line length.