Proposal: Go should have generics • Hacker News Board

Re: Proposal: Go should have generics

#351

Post by fauigerzigerk » Thu, Apr 14, 2016, 6:20 PM UTC

sievebrain wrote: post #323

fauigerzigerk wrote: post #315

Earlier quoted context omitted.

Value types are the main culprit behind Java's insane memory consumption. I found out through weeks of testing and benchmarking. I mostly benchmarked a small subset of our own applications and data structures. We use a lot of strings, so I never even started to use Java's String class, only byte[]. I tried all sorts of things like representing a sorted map as two large arrays to avoid the extra Entry objects. I imple…

I admire your dedication to optimisation! But I think your conclusion is not quite right. I said above that pointer overhead is only one source of Java memory consumption, and pointed to (hah) strings as another source. You replied and said no, it's all pointers, followed by "I never even started using strings". Do you see why that approach will lead to a tilted view of where the overheads are coming from? If your ap…

>You replied and said no, it's all pointers, followed by "I never even started using strings". Do you see why that approach will lead to a tilted view of where the overheads are coming from?

I see what you mean, but when I said that Java uses two or three times as much memory as Go or C++, I didn't include tons of UTF-16 strings either, assuming most people don't use as many strings as I do. If your baseline does include a large number of heap based Java String objects, the difference would be much greater than two or three times because strings alone would basically double Java's memory usage (or triple it if you store mostly short strings like words using the short string optimization in C++ for comparison)

>In theory, especially once value types are implemented, it would be possible for a Java app to have better memory usage than an equivalent C++ app, as bytecode is a lot more compact than compiled code

I'd love to see that theory :-) But let's say it was magic and the bytecode as well as the VM itself would require zero memory, any difference would still only be tens of MB. So it would be negligible if we're talking about heap sizes on the order of tens or hundereds of GB.

Re: Proposal: Go should have generics

#352

Post by robwilliams » Thu, Apr 14, 2016, 6:21 PM UTC

Animats wrote: post #49

Generics as a language retrofit tend to be ugly. See C++. I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generi…

C# generics work beautifully and they were retrofitted. Later language additions like LINQ and extensions take advantage of generics as well.

Re: Proposal: Go should have generics

#353

Post by akavi » Thu, Apr 14, 2016, 6:23 PM UTC

NateDad wrote: post #349

akavi wrote: post #336

Earlier quoted context omitted.

What does the implementation of `byName` look like? I'm not sure I understand what its return type would be.

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?

Re: Proposal: Go should have generics

#354

Post by pklausler » Thu, Apr 14, 2016, 6:27 PM UTC

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…

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 same type with distinct comparators, you'll obviously need to distinguish them, as in e.g. "osSort = sortBy (compare `on` os)".

Re: Proposal: Go should have generics

#355

Post by stcredzero » Thu, Apr 14, 2016, 6:34 PM UTC

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…

Your comment is illustrative of a lack of awareness of context. You don't specify the context, but it seems like you're stuck in this academic/language theory mindset. From that standpoint, I rather like generics. It's clear to see how they can enable DRY if used judiciously. (Clear from even a freshman CS undergrad perspective.)

However, as a professional who gets paid to wrangle C++, I find the "Tragedy of the Commons" that results from every bright-eyed recent grad wanting to leave their mark on a system...tiresome. I recently fixed a bug caused by a small find-replace mistake, where a static_cast was left out, resulting in an int() operator being generated by a confluence of preprocessor macros, inlined functions, and composed templates, where the call breaking in the stack trace was expressed nowhere in the code-base. It's one thing to DRY, but taking it one step too far to "Don't State Yourself In The First Place" is way too implicit. Abstractions have a cost, and sometimes the cost is epiphenomenal and gets paid years afterwards.

An argument from ignorance isn't much of an argument.

The decision of the Go team to not include generics is conservative and pragmatic. The context they consider is across an entire language community, and their decision is informed by observations made on code-bases at Google and elsewhere. How many 500k+ line code bases that have been around more than a decade have you worked on? I'm on something like my 4th. My conclusion from that is that we programmers as a group are mostly too anxious to be "clever" and biased towards doing too much when they evaluate the cost-benefit of "clever."

Do you have good data/experience on the epiphenomenal harm done by many, many "clever" programmers over years?

Re: Proposal: Go should have generics

#356

Post by serge2k » Thu, Apr 14, 2016, 6:37 PM UTC

treehau5 wrote: post #274

idobai wrote: post #117

Earlier quoted context omitted.

You forgot that most of golangers are ex-php programmers and students with no experience. Just look at what they're talking about: they think generics are the opposite of simplicity and can make performance and compilation time worse. Meanwhile, Nim has generics with other useful features and has faster compilation time along with better optimization. If google would put 'goto' into go golangers would still use it an…

> You forgot that most of golangers are ex-php programmers and students with no experience. How hopelessly smug and incorrect.

It's a conversation about go, isn't being smug and/or incorrect fundamental to participating?

Re: Proposal: Go should have generics

#357

Post by AnimalMuppet » Thu, Apr 14, 2016, 6:39 PM UTC

d4rkph1b3r wrote: post #326

NateDad wrote: post #301

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

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

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

You missed one word: "significantly". Sure, abstractions help. That wasn't the claim. The claim was that, in a million lines, the lack of that particular way of doing abstractions did not significantly hurt.

Would it have helped? Sure. Would it have helped enough to matter "very much"? No (by NateDad's standards, which may differ from yours).

67 implementations of sort.Interface? Sure, I don't like it, but in a million lines, you've got much bigger things to worry about.

Re: Proposal: Go should have generics

#358

Post by stcredzero » Thu, Apr 14, 2016, 6:40 PM UTC

NateDad wrote: post #338

stcredzero wrote: post #327

Earlier quoted context omitted.

Too often I've seen [X] lead to complexity and abuse which greatly outweigh their utility. Programmer hubris is a problem. There was a widely acknowledged problem in Smalltalk with the overuse of #doesNotUnderstand: and other esoterica to do "clever" stuff which then makes it difficult for new programmers to debug and understand the system. There is a reason why certain methodologies emphasize "the simplest thing tha…

Yep. I remember spending a day trying to genericize a Rules Engine type system in C# and finally realized it was idiotic and made the code more complicated, and we'd probably only ever use the code exactly how it was now (i.e. not generic), and so I left it as-is (and to my knowledge, yes, it stayed exactly the same for forever). I see the same tendencies in many programmers - "hey, I want to write this once and cove…

One place where I worked had a rule that you couldn't invoke DRY until something had been repeated at least 3 times. Empiricism wins in the end when the goal is to seek truth.

Re: Proposal: Go should have generics

#359

Post by serge2k » Thu, Apr 14, 2016, 6:41 PM UTC

mikecb wrote: post #312

agentgt wrote: post #230

I have some biased doubts (come from the JVM world) about needing really fast compiling and is often cited as the reason Go does things the way it does (or is). Is binary dependency management just not an option ever? I have a friend that works for Google and supposedly they have a proprietary build infrastructure that will offload the building of C++ code into a cluster. I sort of wish Google open sourced that as I…

The G build system was open sourced: http://bazel.io/

Not the distributed secret sauce though.

> Does Bazel require a build cluster? Google's in-house flavor of Bazel does use build clusters, so Bazel does have hooks in the code base to plug in a remote build cache or a remote execution system. The open source Bazel code runs build operations locally. We believe that this is fast enough for most of our users.

Re: Proposal: Go should have generics

#360

Post by agentgt » Thu, Apr 14, 2016, 6:42 PM UTC

MustardTiger wrote: post #350

agentgt wrote: post #230

I have some biased doubts (come from the JVM world) about needing really fast compiling and is often cited as the reason Go does things the way it does (or is). Is binary dependency management just not an option ever? I have a friend that works for Google and supposedly they have a proprietary build infrastructure that will offload the building of C++ code into a cluster. I sort of wish Google open sourced that as I…

>Is compilation speed really an issue given the use cases for Go? Yes, I find compilation speed to be one of the most important things. But it is not a selling point for go. The go compiler is not very fast, and speed is not an acceptable excuse for a lack of parametric polymorphism. Ocaml has not just parametric polymorphism, but many other basic type system features. And yet ocamlopt is both 5-10 times faster than…

That is what I'm saying (I think we agree). It seems like a focus of Go's simplicity is to improve compilation speed and yet there are languages like Ocaml that do have generics (and a whole lot more) that seem to compile faster.