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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

281–290 of 439 posts

Re: Proposal: Go should have generics

#281

Post by akavi »

NateDad wrote: post #254
insulanian wrote: post #243

My code is full of map, filter, reduce/fold and similar generic reusable functions. How do people deal with such things in Go? Do they really make copies of such functions for every type they're working with? (And by type I don't mean just int/string, but all model entities/classes.)

map and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name f…

Yes, that's so much worse. At least to my eyes.

It's a death by a thousand cuts. That's 3 dense lines that you need every time you map across a collection.

Which obscures whatever else is happening in the rest of the method/function, so now you've got that much more cognitive load to figure out what it's actual core purpose is.

Which may be subtly modified by the writer purposefully, but you miss it because you assume it's the same "it's just map idiom".

Which may be modified by the writer accidentally, but you miss it because you've trained yourself to parse it as a lump and take its correctness for granted.

Re: Proposal: Go should have generics

#282

Post by omginternets »

sievebrain wrote: post #273
krakensden wrote: post #251

Earlier quoted context omitted.

The siren song of just-one-more-layer.

I don't see your point. If you have a collection of source files, then something must search the directory tree to find them and feed them to the compiler ... ideally, only the files that have changed, to give fast incremental compilation. If you use a typical Java IDE like IntelliJ then the program that does that will be the IDE. There is no "one more layer" because that's the first and only layer. If the IDE build…

>typical Java IDE like IntelliJ

So now I need to change my text editor?

Re: Proposal: Go should have generics

#283

Post by saturn_vk »

parenthephobia wrote: post #216
Loic wrote: post #94

Earlier quoted context omitted.

I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "sorting" new kind of "types" every day. The time spent on coding is way more "around" the algorithms than "within" them. I suppose that we will see more and more code generators which will practically remove the need of generics. We already use them without co…

I don't think we will. The Go community doesn't hate protocolbuffers, but it does tend to think that generics are evil and shouldn't exist. I'm certain that generic generators will be shunned by the community at large, due to solving a problem they don't believe needs solving. Without the network effect to build up a user and developer-based, they'll languish in obscurity. I sure would like to be wrong, though!

I haven't seen any indication that the community hates the idea of having generics. The contrary seems to be the case.

Re: Proposal: Go should have generics

#284

Post by jackielii »

NateDad wrote: post #254
insulanian wrote: post #243

My code is full of map, filter, reduce/fold and similar generic reusable functions. How do people deal with such things in Go? Do they really make copies of such functions for every type they're working with? (And by type I don't mean just int/string, but all model entities/classes.)

map and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name f…

And also you don't have to remember all the different functions, only a for loop to learn.

Re: Proposal: Go should have generics

#285

Post by junke »

NateDad wrote: post #271
junke wrote: post #260

Earlier quoted context omitted.

The problem with code duplication is not about being lazy, or having to type. I love typing. When you dive into a codebase full of vaguely similar yet different blocks, it starts being more than mildly annoying to understand the intent of the code and make the correct change.

nobutseriously... type userList []*User func (u userList) Len() int { return len(u) } func (u userList) Swap(i, j int) { u[i], u[j] = u[j], u[i] } func (u userList) Less(i, j int) bool { return u[i].Name() What change would you ever need to make to this code that would be at all difficult? The first two methods on userList are never ever ever going to change. The only thing you could possibly want to change is how to…

Not all duplication is bad in all cases. It is more a factor of quality, not a direct, causal relationship. See for example this review of publications about code duplication: http://eprints.eemcs.utwente.nl/15314/01/ewic_ea09_s4paper2.....

Re: Proposal: Go should have generics

#286

Post by dominotw »

NateDad wrote: post #279
dominotw wrote: post #259

Earlier quoted context omitted.

>> But, really, is that so much worse than this? names = [m.Name for m in machines] You can take that code and interpret that as database query, like C# LINQ. you frist example is 'how' vs 'what' of second example. Once you stop telling the computer how to do things and just tell it what you want all kinds of things become possible.

But then you have no idea what the computer is actually doing . There's a big performance difference between an in-memory loop and querying a database. This is one of the things I like about Go... what the computer actually does in response to any random line of code is pretty obvious (except for function calls, which of course can do anything). When you hide away the loop inside a map statement, you get people doing…

>But then you have no idea what the computer is actually doing.

You trust it the same way you trust go compiler to do the right thing when you give it code to compile.

Re: Proposal: Go should have generics

#288

Post by sythe2o0 »

dominotw wrote: post #259
NateDad wrote: post #254

Earlier quoted context omitted.

map and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name f…

>> But, really, is that so much worse than this? names = [m.Name for m in machines] You can take that code and interpret that as database query, like C# LINQ. you frist example is 'how' vs 'what' of second example. Once you stop telling the computer how to do things and just tell it what you want all kinds of things become possible.

It's worth noting you'd probably want to write this out in Go as follows:

  names := make([]string, len(machines))
  for i, m := range machines {
      names[i] = m.Name
  }
append() is pretty costly, and should be avoided when possible for performance. This is actually relevant to your how vs what concern-- on the one hand, we could trust the compiler and the builtins to always take the most efficient approach, and only program 'what' we want. That could avoid something like using append in a loop where you know the length of your intended output slice. On the other hand, if there are edge cases which the built-ins take into account that we don't care about and want to ignore, being able to and having the intention of programming 'how' can have performance benefits.

I like writing 'how' because I get to benchmark and test different approaches to solve the same problem, whereas 'what' might take a usually-fast approach that isn't a good solution in our specific case.

Re: Proposal: Go should have generics

#289

Post by tacos »

Arzh wrote: post #278
alkonaut wrote: post #202

Earlier quoted context omitted.

If code generation is used to make up for something missing in a language (be it generics, metaprogramming etc.) then that's a pretty clear sign something is wrong. It's definitely acceptable to use a workaround for a missing feature once or twice in a language, because no language is perfect, and no language benefits from being burdened with all features imaginable. But if a workaround becomes part of the day-to-day…

Code generation is not about a deficiency in the language, C++ has templating but I will often use code generation since you only need to run that once and templating bloats the compile time for ever.

Junior programmer alert.

Re: Proposal: Go should have generics

#290

Post by tmaly »

mattlondon wrote: post #68

I can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not ev…

I agree with the Sort issue, I faced the same problem. However, I cannot see how generics would fit well into code that is supposed to be easier to understand and maintain.
Post reply on HN