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

41–50 of 261 posts

Re: Why Generics?

#41

Post by _ikke_ »

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…

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 generics don't add a lot.

Re: Why Generics?

#43

Post by RHSeeger »

dimgl wrote: post #7
mlevental wrote: post #4

why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional tr…

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

I see you program in Blub (http://www.paulgraham.com/avg.html).

Re: Why Generics?

#44

Post by jerf »

silasdavis wrote: post #29
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.

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 Go, like, for instance, an immutable tree. Granted, it'll still take some care to use properly in Go as it does not have "const" or anything like it, but it can still be done. The problem I have is not with accidental mutation, but that I just don't want to sit there and implement the immutable tree code. (Trees are great, but they're really tedious to write in the best of times, and nightmares to debug in the worst.)

I'm not terribly interested in trying to jam functional programming into Go; I may make light use of map/filter/reduce but even if this was fully implemented it would still be a fairly unpleasant experience (function that return "a value and an error" aren't much fun to map and can't hardly "chain" at all). But I've missed being able to just grab a particular data structure a few times.

Re: Why Generics?

#45

Post by bbatha »

dimgl wrote: post #7
mlevental wrote: post #4

why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional tr…

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

If the std lib had functions that mapped to the "Slice Tricks"[0], like virtually every other language, I'd use them constantly. Sure I wouldn't write generic functions all that much, but calling generic code I would do every day and it would be a serious ergonomic, correctness, and readability improvement to have named functions for very common patterns like the slice tricks.

0: https://github.com/golang/go/wiki/SliceTricks

Re: Why Generics?

#46

Post by silasdavis »

Filligree wrote: post #9

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.

Perhaps I'm misunderstanding, but I would have thought go already implements typeclasses and this proposals extension to the interface semantics is a parametric typeclass?

Would you mind elaborating?

Re: Why Generics?

#47

Post by Vendan »

elpakal wrote: 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.

Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing.

That said, I do want generics to come to Go, just... with an emphasis on what Go is, not just "here, let's replicate X's generics in Go". I am interested in the contracts implementation.

Re: Why Generics?

#48

Post by jerf »

sansnomme wrote: post #21

I think another area of Go that could use improvements is a more portable standard library optimised for embedded and OS dev. A lot of people want to use Go as a "systems language" and do drivers etc. in it. But the standard library don't have good support for freestanding, or at least it's not a priority. C and Rust and other languages designed for usage in a non-hosted environment have very clear delineated areas o…

"Go's runtime by default assumes the presence of an operating system."

It also assumes the existence of several megabytes of runtime and enough RAM to feasibly use GC, which if nothing else is probably a real mess when it comes to drivers.

What you probably need, rather than being a second-class citizen of the main Go language indefinitely, is a separate dialect that is close to Go, but can go its own way if it makes sense, like: https://tinygo.org/

Re: Why Generics?

#49

Post by whateveracct »

dimgl wrote: post #7
mlevental wrote: post #4

why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional tr…

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

If you're writing loops that build up some accumulator, you could use generics. Even if you don't see that.

Re: Why Generics?

#50

Post by hinkley »

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.

I'm a little surprised the word 'mixin' appears nowhere in that article.

Josh Bloch argued against the interface solution in Java (and in particular, read-only versus read-write interfaces), claiming there would be too many interfaces and it would confuse users, and that didn't sit right with me. To me it's his second-biggest sin against Java, and it's tied to the first.

The only truly unforgiveable one is UnsupportedOperationException. The guy who wrote the collections API for Java didn't know the first thing about the Liskov Substitution Principle, and gave the world an implementation that violates it because the alternative would have been too difficult for people to understand? Rot in hell forever, Josh. And take your Effective Java with you to throw on the pyre. I can't write effective Java and it's partly your fault.

At the time I was experimenting with my own language API design, so I sat down and figured out how many interfaces it would take. I came up with around 20% more than the selected design. You'd think it would be bigger, but the critical observation is that a lot of generic collections vary only on write operations.

Read operations are often identical, and if the surface area for reads is small, then a functional programming style is more reasonable. Which may explain why so many functional programming languages appear to other people to have an anemic collections API. What I'd love to know is if any of them use different implementations under the hood for small sets/lists versus large ones. If they do, I don't hear anybody bragging about it.

Post reply on HN