Live data from Hacker News

Why Generics?

blog.golang.org

51–60 of 261 posts

Re: Why Generics?

#51
post #13

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.

What sort of horrible experiences have you actually had with ORMs? Every time I've used one it's been an absolute joy, I hate repeating myself in my DB, in SQL, in mapping code and again in application code. The main thing I see people complaining about is performance edgecases, but for small and mid scale applications these can never take away the massive DRY principle gain good ORMs provide.

Re: Why Generics?

#52
post #28

Chiming in here as a Swift dev - I find its generics system incredibly helpful and end up writing something that uses generics about once a month. To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable.

> To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable.

There was a story I came across once. It went something like this:

The proponents of every gizmo think their gizmo is superior to the others, because it's got these useful features that the others lack, and isn't encumbered by the weird useless stuff those other languages have.

If only they spent time to understand those "weird useless features"...

Re: Why Generics?

#53

Why generics, indeed? There must be an answer to this, but I've never seen a good response to why they aren't implementing parametric types and (single-parameter) typeclasses instead. Simplicity? Yes, but generics are hardly any simpler.

For me, generics make api designer's life harder, but api user's life easier. A good enough reason for me.

Re: Why Generics?

#54
post #44

Earlier quoted context omitted.

Probably yes: https://medium.com/@arschles/go-experience-report-generics-i... Many smaller projects would benefit too. I would like to build a typesafe tree for an efficient sorted map, and to be able mergsort over multiple trees of different types. It would allow some extremely useful channel combinators for doing rather common things like safely shutting down a service with some background processing. Often these t…

I have been vigorously pro-generics since the beginning, and this is the reason why: I want generic data structures. Arrays&slices and maps are great, and they really are the 90/10 solution a lot of the time, which is precisely why putting direct support into your syntax for the two of them is so very, very popular, but that other 10 comes up. Plus, there are some generic data structures that will really work well in…

I agree with the 90/10. An example of something I use in its non type safe generic form that would benefit: https://github.com/eapache/channels

Re: Why Generics?

#55
post #13

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.

And almost every usage of Dapper relies heavily on generics.

Re: Why Generics?

#56
post #13

Earlier quoted context omitted.

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…

The sqlx package is a similar Go wrapper around SQL. Very handy for scanning into structs.

Re: Why Generics?

#57
post #41

Earlier quoted context omitted.

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…

The benefit is that you can remove a lot of duplicate code that does exactly the same, except the type it operates on. The blogpost talks about the Reverse function. Especially when you need to make changes, (fix bugs, performance improvements, etc), if you have dedicated functions for these, it takes effort to keep them (plus tests) in sync. If you don't see any issue with this duplication, then I can see that gener…

its just not that much code usually. I would like to see an example of this "a lot of duplicate code" scenario. Most code sharing is done by super classes. Generics seem more like a syntactic sugar added to type sharing that interfaces already allow.

Re: Why Generics?

#58
post #23
post #5

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

What is HKT?

Higher-kinded types. Generics that take generics as parameters. They allow things like writing a function that both takes and returns any container type you can map over with different (defined) element types. Given how hard arity-0 generics have been to get into Go, I suspect that the chances of HKT making it are slim to none (but I think that the grandparent knows that and is just being funny).

Re: Why Generics?

#59
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.

https://en.wikipedia.org/wiki/Kubernetes says original Kubernetes was all C++.

Re: Why Generics?

#60
I hope this doesn't happen. I love golang because it is simple and easy to read. Both will go away when generic programmer start to write unreadable meta-programming class which "you don't need to understand, just use them".

I admire golang devs for being opinionated and stand up for the core lines of their language so far.

I see generic as renouncing these principles.

Post reply on HN