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

Why Generics?

blog.golang.org

Post reply on HN
Print view View original

31–40 of 261 posts

Re: Why Generics?

#31

Post by yureka »

YawningAngel wrote: post #22
haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

Kubernetes is a transpiled Java project, so yeah, Java-like features would definitely make it easier :P I think idiomatic golang works pretty well without generics in most cases, the big problem for me is that functional programming is essentially impossible without them.

Can you provide some resources on what makes you think Kubernetes is a transpiled Java project?

That's definitely not the case from what I know/understand...

Re: Why Generics?

#33

Post by mlevental »

reificator wrote: post #14
mlevental wrote: post #12

Earlier quoted context omitted.

That's because you write a particular kind of program. Notice that there are no good ORMs or numerical libraries. Both of these are use cases for generics. Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).

> Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one). Yep. I held this opinion before Go came out, only because I couldn't write an ORM in Go.

i said the go community - not the developer community. you couldn't have had that opinion as a go user before go came out.

Re: Why Generics?

#34

Post by runevault »

dimgl wrote: post #13
mlevental wrote: post #12

Earlier quoted context omitted.

That's because you write a particular kind of program. Notice that there are no good ORMs or numerical libraries. Both of these are use cases for generics. Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).

Developers think ORMs are evil because they've had horrible experiences with ORMs in general. I'm one of them. The only ORM that I enjoyed using was Dapper, and it's barely an ORM.

Dapper really is such a weird edge case. You still write all the sql, all it does is the conversion from a type to the input parameters and the returned rows into objects where the row names match the parameters of the class. Frankly I feel like that's the right way to build ORMs in all languages that have the facilities to manage it (and maybe those that don't you pass in a function pointer to do the dumping of rows into type for you)

Re: Why Generics?

#35

Post by silasdavis »

archy_ wrote: post #20
haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

Agreed on keeping the status quo, adding generics makes it really easy to write bad code and increases mental overhead. Simplicity is what we should be going for, not having generics should've been kept as a selling point.

This may be practical from the point of view of 'top level applications' in Go. But there is a lot of murk in pure Go implementations of databases, and datastructure heavy libraries that could be avoided and lead to better testing and less duplication. If you find it simpler to avoid generics that ought to be possible under this design.

Re: Why Generics?

#36

Post by sli »

olooney wrote: post #23
moomin wrote: post #5

Go 3: Why HKT? Go 4: Why homoiconicity? Go 5: Why uniqueness and borrowing?

What is HKT?

Generics are to types what HKT are to type signatures. In functions, they usually map to arity. That is, an arity mismatch is are a higher-kinded type mismatch. An easy (if not totally accurate) way to view them is like doubly-generic types.

If you have some type A, it has the kind * . If you have some function from A -> B, it has the kind * -> * .

Re: Why Generics?

#37

Post by btilly »

haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

Which interfaces-based solution?

The one used by sort is a hack that only works for some of the things that you would want to do.

The one where you use introspection performs badly and isn't typesafe.

The tree implementation in the article cannot be done in a safe and performant way in Go today.

Re: Why Generics?

#38

Post by dimgl »

stouset wrote: post #16
dimgl wrote: post #7

Earlier quoted context omitted.

I have yet to find one practical application for generics in the apps I've built in Go.

And I had yet to find a single practical application for closures, right up until the moment I started using Ruby (and later, Rust). Turns out that they’re so useful in practice that they’ve been bolted on to—as far as I can tell—nearly every language in widespread use today. None of these languages “needed” such an improvement. Billions of lines of Java and C# were written without this feature. And yet today it woul…

I feel like closures are a consequence of having functions as first class citizens, so it's not exactly a direct comparison. But I guess I see your point.

Re: Why Generics?

#39

Post by tuvan »

yureka wrote: post #31
YawningAngel wrote: post #22

Earlier quoted context omitted.

Kubernetes is a transpiled Java project, so yeah, Java-like features would definitely make it easier :P I think idiomatic golang works pretty well without generics in most cases, the big problem for me is that functional programming is essentially impossible without them.

Can you provide some resources on what makes you think Kubernetes is a transpiled Java project? That's definitely not the case from what I know/understand...

There is a talk about it you can find here: https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...

Re: Why Generics?

#40

Post by silasdavis »

freetobesmart wrote: post #27
rad_gruchalski wrote: post #10

Earlier quoted context omitted.

Every project I’ve written so far in golang could benefit from generics.

but what is the benefit? How does your code change. Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal. Its lack of impact is why I dont really care about the subject. Adding or removing generics to a project matters little. So why bother…

Go strongly discourages you from making extremely useful abstractions over types early on in your design. You don't just write things the same way and remove boilerplate with generics you can exploit more symmetries.
Post reply on HN