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

121–130 of 261 posts

Re: Why Generics?

#121

Post by rad_gruchalski »

freetobesmart wrote: post #57
_ikke_ wrote: post #41

Earlier quoted context omitted.

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.

Have a look at viper.

Re: Why Generics?

#122

Post by astrobe_ »

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…

> why are people obsessed with simplicity? > "make things as simple as they can be but no simpler".

Those people are obsessed, precisely, with the "can be".

Re: Why Generics?

#123

Post by iainmerrick »

shaded-enmity wrote: post #114
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

What is your point? Serious question. If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.

I’d compare it to e.g. the work on async/await in Rust, where the discussion seems more directly “we like this feature that C# pioneered and JS has adopted, here’s how we plan to adapt it to make it work well with Rust.”

Admittedly, the Rust async/await RFC and the Go contracts proposal both discuss prior art in sections towards the end, so they are actually similar in that respect. Maybe it’s really just a question of tone and messaging, and the particular discussions that tend to end up on HN.

Re: Why Generics?

#124

Post by aczerepinski »

aldanor wrote: post #117
aczerepinski wrote: post #98

Mixed feelings about this. One of my favorite things about Go is that it's a small and relatively simple language. It's a "fast enough" language without the steep learning curve of Rust. Too many features that make sense individually could change the calculus to "might as well use Rust".

I'm not so sure about the "steep learning curve of Rust" stereotype anymore. If you are comfortable with low-level programming languages in general, in a few days you can get yourself started fairly quickly with Rust to the point where you will still battle with compiler re: borrowing and related things, but will be able to write functional code. Coming from pure Python/JS will be tough, but it will be the same with…

My work is a Ruby/JS shop, and we have some Go in production as well. We definitely need a little hand holding to ramp anybody new up on the Go codebases. In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. I've written just barely enough Rust to say there are even more concepts that would be new to my team.

Even with Go being comparitvely simpler, I could go either way on whether it was the right choice to add it to the stack.

Re: Why Generics?

#125

Post by jayd16 »

shaded-enmity wrote: post #114
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

What is your point? Serious question. If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.

>then I have to be familiar with the full semantics of C# generics

Or you could research the very detailed discussion and documentation available on the topic of C# generics.

Re: Why Generics?

#126

Post by Vendan »

Nevermindmine wrote: post #109
Vendan wrote: post #47

Earlier quoted context omitted.

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…

> Generics are awesome, but always seem to add a ton of complexity The team I work in use generics all the time and I'm not sure what complexity you are referring to. Care to elaborate? Is it some edge cases or are you talking about from a compiler perspective or something else? To me, not having generics is like saying let's skip handling bools and just store them in strings as "true" or "false". It's such a weird t…

Compiler perspective (fast compiles are a core part of Go, IMO), various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2), and seeing code bases that get out of control with generics and such.

Note that, for all of that, I'm still in favor of adding generics in Go, as I do see the value they can add. I'm just pointing out that "bashing" on Go devs on not knowing what generics are or how they can be useful is both non-productive and probably generally wrong. Plenty of us are saying "Man, if I had generics, this would have been less code/cleaner/more reusable!", just the other various tradeoffs outweigh the actual cost of using a different language. Go's ability to drop a very junior dev (or just one that has never use Go) into a codebase and have them be almost immediately productive is incredible.

Re: Why Generics?

#127

Post by jayd16 »

weberc2 wrote: post #85
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

It seems like you’re objecting to the messaging (not referencing an existing language, which doesn’t work for people not familiar with the implementation of that language) and also that, at its inception, Go didn’t pick (randomly?) a language off of which to model its generic implementation. Am I misreading?

Referencing existing work is not an rare or fanciful concept. If you're not familiar with prior work that's referenced in a paper then you can research that prior work as well. If prior work has not been referenced or addressed its usually considered a flaw.

Re: Why Generics?

#128

Post by baby »

I have two comments to make about this proposaL:

1. The type should indicate a generic, not a new syntax. This is better because it is easier to parse for the human eye. For example:

  func Reverse(first _T, second _T)
2. Since all of what generics are is a compile-time code generator, I suggest that Golang forces developers to explicitly list what types are using the generic:

  generics(Add) = {int, string, car, food}
  func Add(first _T, second _T)
This list can be added to, after importing the package:

  Import “thing”

  generics(thing.Add) += {stuff}
This makes code very explicit about its generic functions. It also allow readers to understand exactly where the function is used.

Re: Why Generics?

#129

Post by shaded-enmity »

jayd16 wrote: post #125
shaded-enmity wrote: post #114

Earlier quoted context omitted.

What is your point? Serious question. If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.

>then I have to be familiar with the full semantics of C# generics Or you could research the very detailed discussion and documentation available on the topic of C# generics.

How is your suggestion not equivalent to "be familiar with full semantics of C# generics"? How does that help me with being productive using Go's implementation of generics, which has fundamentally different type system and syntax to begin with?

Re: Why Generics?

#130

Post by [deleted] »

grumdan wrote: post #104
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

[deleted]
Post reply on HN