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

301–310 of 439 posts

Re: Proposal: Go should have generics

#301

Post by NateDad »

I work on juju (https://github.com/juju/juju), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing).

Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly difficult part of my job? No.

Juju is a distributed application that supports running across thousands of machines on all the major clouds, on OSes including CentOS, Ubuntu, Windows, and OSX, on architectures including amd64, x86, PPC64EL, s390x... and stores data in a replicated mongoDB and uses RPC over websockets to talk between machines.

The difficult problems are all either intrinsic to the solution space (e.g. supporting different storage back ends for each cloud), or problems we brought on ourselves (what do you mean the unit tests have to spin up a full mongodb instance?).

Generics would not make our codebase significantly better, more maintainable, or easier to understand.

Re: Proposal: Go should have generics

#302

Post by sythe2o0 »

nostrademons wrote: post #264
justinlardinois wrote: post #247

Earlier quoted context omitted.

What's wrong with nil? Just legitimately curious, and I've never used Go at all.

It means that every single type in the language has one extra value it may contain, 'nil', and your code will crash or behave erratically if it contains this value and you haven't written code to handle it. This has caused billions of dollars in software errors (null dereferences in C/C++, NullPointerExceptions in Java, etc.). See "Null References: The Billion Dollar Mistake" by Tony Hoare, the guy who invented it: h…

nil in Go doesn't work that way. Most types cannot be nil.

Re: Proposal: Go should have generics

#303

Post by pythonistic »

omginternets wrote: post #282
sievebrain wrote: post #273

Earlier quoted context omitted.

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?

If you're using a text editor, your IDE is likely the CLI.

Re: Proposal: Go should have generics

#304

Post by NateDad »

junke wrote: post #285
NateDad wrote: post #271

Earlier quoted context omitted.

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

Yes, I agree completely. Take leftpad, for example....

And more seriously, there are times when factoring out "common" code makes the code significantly more complicated, and often turns your common code into a morass of special cases as your application progresses, and these cases that looked "the same" end up being "not quite the same".

Re: Proposal: Go should have generics

#305

Post by NateDad »

sythe2o0 wrote: post #288
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.

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…

Yeah, true. And in production, that's what I do. Append is for when you don't know how long a slice will end up being.

Re: Proposal: Go should have generics

#306

Post by xenadu02 »

lucozade wrote: post #209
reycharles wrote: post #92

Earlier quoted context omitted.

Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO. > I w…

I quite like the logical progression though: + People keep telling me we should be able to implement a map function in go. + I implemented a map function in go. + The map function was ugly, slow, unsafe and generally an abomination. Conclusion? You don't need a map function in go. You may not agree but you have to admire his dedication to the One True Way whatever is put in his way. Even if it's him that's erecting p…

It's the equivalent of PHP developers claiming the way PHP works if great.

I've used generics in several languages now and it's so awesome for reducing boilerplate and duplicated code.

The guy is just flat out wrong.

Re: Proposal: Go should have generics

#307

Post by NateDad »

dominotw wrote: post #286
NateDad wrote: post #279

Earlier quoted context omitted.

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.

That's the nice thing about Go code... I almost always know exactly what it'll make the computer do. I know how much memory will get allocated, what the likely CPU usage is going to be, etc. The abstraction between the code and the computer is low, which helps lets a lot in understanding why your code is slow, or why it's producing a lot of garbage. "oh hey, here's a loop in a loop... oops, N^2 time".

Re: Proposal: Go should have generics

#308

Post by myg204 »

waimbes wrote: post #277
_uhtu wrote: post #244

Earlier quoted context omitted.

Dart is also Google sponsored and no one uses it despite the fact that it's actually a pretty great general purpose language. People use go because it's productive and had a PHENOMENAL standard library for networking.

> Dart is also Google sponsored and no one uses it despite the fact that it's actually a pretty great general purpose language. Citing an example that had support from Google and failed does not refute the claim that Go would have failed if not for Google's support.

It clarifies the fact that Go is successful for more reasons than just being pushed by Google. So it focuses the question to "what is it that people like about it". And then we can have a better conversation.

Re: Proposal: Go should have generics

#309

Post by NateDad »

akavi wrote: post #281
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…

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 assum…

Actually readability at the point of use is very reader-friendly:

    machines := db.GetAllMachines()
    sort.Sort(byName(machines))
For those not familiar with Go, the sort.Sort line is converting the list of machines into a type that matches the interface that sort.Sort expects. The list of machines is sorted in-place

The only part that can be subtly changed is the Less function, which determines the sort order. And as I've said elsewhere... that definition of sort order is something you have to define in any language (for non-trivial types).

Re: Proposal: Go should have generics

#310

Post by andrewstuart2 »

dsymonds wrote: post #6
andrewstuart2 wrote: post #4

Earlier quoted context omitted.

The proposal document itself may have existed for that long, but it's only been public for 14 days. To me, the important portion is the link to the discussion issue [1] created 2 hours ago, which to me seems like a more significant step towards doing the actual work. Before, the default response was "we're thinking about it." Now, it's "let's all talk about it." [1] https://github.com/golang/go/issues/15292

It's not so much "let's all talk about it", but "here's how detailed a proposal needs to be to make it worth considering".

Sorry, I mean the opening of a Github issue regarding generic programming by the Go team itself is the beginning of a new stance.
Post reply on HN