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

361–370 of 439 posts

Re: Proposal: Go should have generics

#361

Post by NateDad »

pklausler wrote: post #354
NateDad wrote: post #347

Earlier quoted context omitted.

Aside from trivial types, like strings or integers, how does the language know how to sort a list of values, if you don't tell it how to? Translate this into whatever language you like: Machine { Name string OS string RAM int } You have 3 places that want to sort a list of machines, one by name, one by OS, and one by RAM. You're telling me there's a language that can do that without having to write some kind of code…

Sorting on all three fields in priority order is what I had in mind, and that's trivial in Haskell by adding "deriving(Ord)" to the data type definition and then just using the standard "sort :: Ord a => [a] -> [a]". If you're always going to sort them based on some (other) relation between the fields, make your type a custom instance of Ord, e.g. "instance Ord Machine where compare = compare `on` name". To sort the…

So... you will still need 57 spots in the code where you define how to sort a type.

Maybe my reference to sort.Interface is confusing people. When I say we have 57 implementations of sort.Interface, that's 57 different types and/or different ways of sorting one of those types. So, like, sorting Machine by Name would be one implementation, sorting Machine by Name then OS then RAM would be another implementation. You write an implementation of sort.Interface for every type, and for each way you would like to be able to sort it.

An implementation of sort.Interface just requires three methods:

    Len() int // return the length of the list
    Swap(i, j int) // swap items at indices i and j
    Less(i, j int) bool  // return true if list[i] is less than list[j]
It's the implementation in Less that determines the order.

That's not really so different than what you're describing in Haskell, it's just not part of the type, it's a new type that you convert the original type into, to pass into the sort.Sort() function (and because the underlying type is a slice, which is a glorified struct with a pointer to an array, that also sorts the original value).

Re: Proposal: Go should have generics

#362

Post by jimbokun »

NateDad wrote: post #347
pklausler wrote: post #340

Earlier quoted context omitted.

> But in any other language, we'd still have the same 57 definitions of how to sort a type... That claim turns out to not be the case.

Aside from trivial types, like strings or integers, how does the language know how to sort a list of values, if you don't tell it how to? Translate this into whatever language you like: Machine { Name string OS string RAM int } You have 3 places that want to sort a list of machines, one by name, one by OS, and one by RAM. You're telling me there's a language that can do that without having to write some kind of code…

The canonical solution to this problem is to provide a function to perform the comparison, or to require the types implement a "Sortable" or "Comparable" interface.

Re: Proposal: Go should have generics

#363

Post by junke »

NateDad wrote: post #335
d4rkph1b3r wrote: post #326

Earlier quoted context omitted.

>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…

> >Do we have 67 implementations of sort.Interface? > Hahaha. This has to be satire right? Nope. /home/nate/src/github.com/juju/juju$ grep -r ") Less(" . | wc -l 67 (granted, 10 are under the .git directory, so I guess 57) But in any other language, we'd still have the same 57 definitions of how to sort a type.... we'd just have 3 fewer lines of boilerplate for each of those (which live off in the bottom of a file so…

Just to nitpick, that is 4 lines because you add a type too. Also, I noticed this in controller.go:

        // Unreachable based on the rules of there not being duplicate
	// environments of the same name for the same owner, but return false
	// instead of panicing.
	return false
Guess what, I worked with a sort function with the same kind of assumptions, but the implicit rules was broken: the "should never happen" path happened (names were not unique, after all). I found about that only after I wrote my own sort which was careful enough to check that the order was indeed total and when results diverged for some tests. I really disliked that because sorting was an important part in that tool (maybe it is not in yours).

Re: Proposal: Go should have generics

#364

Post by zimbatm »

d4rkph1b3r wrote: post #334
stcredzero wrote: post #329

Earlier quoted context omitted.

Generics are literally a form of abstraction Is your unstated assumption then that all forms of abstraction must be used? If you've done substantive projects, you'll come to realize that abstractions have a cost, and that everything should be considered on a cost/benefit basis. You might as well be arguing that abstraction doesn't help. This is a black and white binary fallacy invoked to then create a straw man, whic…

can you articulate the exact cost of adding generics? The benefits are profound, and the PL community has been doing research on it for the last forty some odd years. Some of the benefits are opportunities for * specialization * reduction in boilerplate * parametricity * free theorems * type classes Objectively, a collections library written with generics and no subtyping will be much better and cleaner than a subtyp…

Generics introduce more complexity in the type system which in turn makes the compiler slower.

Generics introduce more complexity for the reader of the code because it's another abstraction to understand.

It's debatable but when your brain is thinking about generics or context-switching because it has to wait on the compiler to finish, it's less time making progress on the actual thing that needs to be done.

Re: Proposal: Go should have generics

#365

Post by AnimalMuppet »

sievebrain wrote: post #189
zzzcpan wrote: post #170

Earlier quoted context omitted.

This will only target a very small group of developers, who are comfortable with JVM, but not with Java or Scala. I don't see any money there. JVM is a major drawback for any language. Many people don't even look at JVM languages.

No, it's the opposite. It would appeal to people who built large Go codebases and eventually realised that they were tied to a toolchain that was years behind the state of the art. A Go for the JVM would immediately give Go developers much better optimising compilers, high quality cross platform IDE-integrated debugging and profiling, much stronger garbage collectors, ability to access the large quantity of Java libr…

Go's unique proposition, IMHO, is compile times. If you have a codebase that's 10 million lines, with 10 or 100 developers working on it for 10 or 20 years, compile times really matter.

Can you build a language that runs on the JVM that compiles as fast as Go? Perhaps. Java sure ain't it, though.

Re: Proposal: Go should have generics

#366

Post by NateDad »

akavi wrote: post #353
NateDad wrote: post #349

Earlier quoted context omitted.

byName is a type. It's a named type based (likely) on a slice of machines. The byName type implements the functions necessary to support the interface that the sort.Sort function requires: type byName []Machine func (b byName) Len() int { return len(b) } func (b byName) Swap(i, j int) { b[j], b[i] = b[i], [b[j] } func (b byName) Less(i, j int) { return b[i].Name sort.Sort takes an interface type that has the methods…

Does all of that have to be implemented every time you want to sort by a new predicate? If so, that seems like quite a lot of boilerplate, no?

Mostly, yes (you can finagle your way out of rewriting Len and Swap if all you need to do is change the Less function, but it's probably not worth it from a code clarity point of view).

In a million lines of code, this costs us approximately 114 extra lines of code beyond the minimum necessary for any language where you need to specify a sort order (assuming you need at least one line of code per type/sort algo to tell the computer how to sort your random list of objects).

So, it depends on what you mean by a "lot".

Re: Proposal: Go should have generics

#367

Post by trhway »

jcoffland wrote: post #311
trhway wrote: post #144

Earlier quoted context omitted.

we see things differently. In my view Linus is speaking free here. Many others refrain from speaking free and truthfully for fear of being called an asshole. I see different main point. In my view Linus narrows the domain of his speech to system-level (not low-level!) code just out of basic intellectual honesty which implies to speak with authority only where your experience and knowledge are.

When he says, " YOU are full of bullshit," is that the intellectual honesty part? Some people are merely assholes constrained by social pressure other people are actually being honest when they are nice. It's hard to believe this when you are one of the former. I agree with your system-level vs. low-level point except that he also talks about git which is neither.

>When he says, "YOU are full of bullshit," is that the intellectual honesty part?

if the guy is full of it then not saying it would be intellectual dis-honesty :). You and me belong to the different mindsets separated by a Grand Canyon. Man, i understand the reasons behind PC-culture, yet i just don't agree with the required trade-off. It is pretty much the same as security vs. privacy & other freedoms - there is really no meaningful debate possible beside clearly stating your own position as these mindsets are separated by the same size canyon. It is not separation of reasoning, it is separation of the choice of the top priority - in most cases that choice is deeply unconscious, and i have my personal theory connecting it to evolution and natural selection :) It is not that people on different sides don't understand the reasons of the other side, it is just people on each side are separated by their choice of the reasoning they assign higher priority to, like me and you in this case.

Re: Proposal: Go should have generics

#368

Post by AnimalMuppet »

loup-vaillant wrote: post #204
thegenius2000 wrote: post #165

Earlier quoted context omitted.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

He who takes his examples of generics from C++ and Java has a huge blind spot. The FP crowd came up with simple and useable generics (Hindley-Milner type inference) in 1982 . It's like Go's creators haven't even read Pierce's Types and Programming languages . This is inexcusable. Even more so from Rob Pike and Ken Thomson —you'd expect better from such big shots.

It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.

Re: Proposal: Go should have generics

#369

Post by twic »

eva1984 wrote: post #89
catfest wrote: post #23

Earlier quoted context omitted.

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

Java itself is, IMHO, quite straightforward. But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced. Language wise, Java recentl…

> Java [...] is still more LOC comparing to Go

My experience is the exact opposite: Go takes more lines to do something than Java.

I would say that in large part, this is because the error handling restricts expressions to a rather small size, and then because without streams, collection manipulation has to be written out longhand.

Re: Proposal: Go should have generics

#370

Post by NateDad »

jimbokun wrote: post #362
NateDad wrote: post #347

Earlier quoted context omitted.

Aside from trivial types, like strings or integers, how does the language know how to sort a list of values, if you don't tell it how to? Translate this into whatever language you like: Machine { Name string OS string RAM int } You have 3 places that want to sort a list of machines, one by name, one by OS, and one by RAM. You're telling me there's a language that can do that without having to write some kind of code…

The canonical solution to this problem is to provide a function to perform the comparison, or to require the types implement a "Sortable" or "Comparable" interface.

yes, which for 57 different types and/or comparison methods requires 57 different functions... which is basically the exact same thing you do in Go. It's just in go, you define a new type based on the original value, rather than just a function.
Post reply on HN