Summary of Golang Generics Discussion

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#

by signa11 • 12 years ago

89 146 12 years ago

docs.google.com

Interesting timing as I had just read a great blog post about getting around the lack of generics in Go entitled "Living without generics in Go"[1] that I found to be very enlightening.

[1] http://www.weberc2.com/posts/2014/12/12/living-without-gener...

kornakiewicz• 12 years ago

That was the way I used to write code when playing with Go, but in long term is necessary to write own wrappers for any tuple {collection, collection method, type}.

BruceIV• 12 years ago

Interesting post, but what the author doesn't seem to realize is that even though he isn't doing much generic programming, someone needs to be able to do it to write the libraries he needs to use. The proposed approach is decent, but it reminds me of wrapping up STL container types in the amount of useless boilerplate needed to achieve a single function (but worse, because here the function is "type safety", whereas when you wrap an STL type it's about e.g. ensuring some invariant on the members of a set)

weberc24• 12 years ago

The author here. I'm not necessarily an opponent of generics, the post was just a "how to deal with the current situation", so keep that context in mind. :)

someone needs to be able to do it to write the libraries he needs to use

I'm not sure what this has to do with what I wrote. As evidenced by the `container/list` package, a generic implementation can be distributed, and we can build our type-safe wrappers around that (if type-safety is really that important in your application--I haven't had much difficulty using the generic container as-is).

I do agree that the boilerplate is inconvenient (pretty much by definition). But it's fortunately also trivial by definition. People seem to think that these wrappers raise the total complexity of the program just because they contribute to the total lines of code (loc) count. Many people also think that if you don't use these type-safe wrappers that your program will be doomed to runtime errors.

I think both of these are big exaggerations, and that's why I wanted to write that post. Even in spite of Go's generics situation (I'm not entirely convinced about the degree to which it's a liability), I still find it to be the most enabling tool in my bucket.

qznc4• 12 years ago

This is Java-style type erasure done manually. So it has the same problem: speed hit due to lots of boxing and unboxing.

coldtea17• 12 years ago

As with any feature it should solve a set of problems, if the problem isn’t solved in the best way possible by the feature then it’s either not a good feature or of very limited value.

This is disingenuous -- just to set an artificial barrier against generics.

Go doesn't solve any problem in the "best way possible":

- "Blessed" containers like Go's hash tables are not "the best way possible".

- The way it handles goroutines/channels has issues (mutability/pointer issues, not pre-emptive, etc). Again, far from "the best way possible" (that would be Erlang maybe).

- The GC was far from the "best way possible" or even "really good". Especially on the earlier versions (and crap on 32-bit).

- Losing type checks by having to use interface{} for generality, or resolving to BS textually generated code with custom string templating is not "the best way possible".

So why only Generics has to be "perfect or bust"?

And then there's this gem, about the (lack of) need for generic data structures:

map/slice suffice for most of the cases encountered in programming.

...

Or this "con", about having generic to help with functional fold/zip/map:

The fastest solution needs to take into account when and which order to apply those transformations, and how much data is generated at each step

So, in other cases the hit from interface{} is OK, but suddenly now those operations have to be "the fastest solution".

(Not to mention that the fastest solution, application order etc are orthogonal to Generics).

GFK_of_xmaspast• 12 years ago

"""So why only Generics has to be "perfect or bust"?"""

Ideology, and a push-back against outside pressure to include them.

commentzorro2• 12 years ago

It seems to be a rite of passage that everyone who gets to a certain point of familiarity with Go has to write an article justifying why you don't need generics. Austerity can be a tough way to live until you become a bit numb.

zerr• 12 years ago

I think mostly it is an incompetence of Go's designers, no matter how they cover it up...

sigzero2• 12 years ago

Then they should just own it and say "Go isn't getting generics ever." instead of making artificial barriers. Which their explanation totally is doing.

lucozade• 12 years ago

If that had been re-worded to "if the problem isn't solved in the most pragmatic way possible" then I would suggest that the sentiment would be a) more in keeping with the general philosophy of Go and b) a justification, sort of, for only supporting map and slice.

Dewie8• 12 years ago

I think you're interpreting that sentence a bit too literally. Clearly the developers of Go are interested in very carefully balancing language features with language complexity (seemingly both for language users and language implementers). And it is in that sense that they probably mean solve in the best way possible, namely to solve a problem in the best way possible with those two concerns - complexity, "expressitivity" - carefully balanced[1].

[1] Though one can argue that the word "best" seems inappropriate when the concern is a very subjective balancing act.

egonelbre7• 12 years ago

Thanks, didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I mentioned on the forum that this document (currently) is highly biased towards my views, this is unfortunate, but this can only be fixed after numerous reviews.

Thanks for pointing out the problems with wording. I'm slowly fixing those. I've changed that "best" to "As with any feature it should solve a set of problems, if there are better ways of solving the problems, those should be used instead."... it's better but not perfect.

"in other cases the hit from interface{}" - added that addition to the alternatives section.

Generics don't have to be perfect, but it must be actually useful and it mustn't compromise simplicity of Go.

NateDad• 12 years ago

Put a big comment on the top DRAFT!! STILL IN PROCESS!! or something.

waps2• 12 years ago

It doesn't mention the major inconsistencies in golang at all.

Go has generics. For arrays, slices, channels, maps, and some "standard" library functions. Go has generic functions. "append" being the obvious example. Go has polymorphic functions : append, make, ... If you look at the compiler source, the type system has generics, to a large extent. It's simply not accessible to normal programmers, instead only allowed for golang's authors.

As if this is not bad enough. Go cheats the type system in thoroughly non-obvious ways to get more C-like behaviours that obviously do not improve safety or programmer productivity.

Go has shudder return value polymorphic functions. Range being the obvious, but not only example (range changes in meaning depending on it's parameters AND on what you assign the result to).

As for your boxing argument. As soon as you use reflect, you're boxing everything. Oh wait, if you use a package that uses reflect, of course you're also boxing everything. Surely that can't be much ... hmmm half the standard library uses reflect. Fmt, everything in encoding, text or html templates, rpc, jsonrpc ... No need for boxing, or compile-time function evaluation or generics (all present better solutions to this, for the CTFE solution see D-lang).

Golang even has functions with type parameters. Make and new being the obvious examples. Again, this is present in the type system (not just there, also in reflect, things like printf, ...). It's simply not made accessible to us lowly go programmers.

So can we please stop with the crap that generics aren't necessary ? That nobody uses advanced type system features ? Or that polymorphism isn't necessary ? It's crap, and obviously the golang authors don't actually believe that. They just think that only they can be trusted to write such functions and that their datastructures are all anyone ever needs. If you disagree with that assessment (and everybody will, soon) Go is not for you.

So Go is simply a throwback to pre-80s programming languages, and a perfect illustration of the frustrations that led to the development and extension of the C++/Java/C# programming languages. If you give people the minimal implementation of sorting an array of structs, it becomes blatantly obvious why other languages are necessary.

The more I write Go, the more I yearn for C++. There is nothing in the C++ language that I can't do for my own datastructures/functions/... That is a huge feature, and may I just say :

From my cold, dead hands !

Btw : there is a better solution to generics as well at compiler-level, that is used in things like the CLR. First, generate unboxed versions of functions where that makes sense. If specializations are possible for 1-bit, 1-byte, 2-byte, 4-byte and 8-byte primitive data types, expand those. Then for anything bigger, like structs, create a boxed implementation, because for structs there is no longer any advantage to working unboxed. Then make it possible to pass in the version to be used in a parameter, so you don't have a combinatorial explosion when many type parameters are given.

e.g. http://research.microsoft.com/pubs/64031/designandimplementa...

coldtea17• 12 years ago

* Thanks, didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I mentioned on the forum that this document (currently) is highly biased towards my views, this is unfortunate, but this can only be fixed after numerous reviews. Thanks for pointing out the problems with wording.*

Thanks for not being defensive and taking my rather harsh critique lightly!

I wasn't trying to attack your specific document either, it's just that those things have often been repeated (often verbatim) by the Go-dev camp.

abroncs• 12 years ago

Not trying to troll, but it's seriously depressing how much time is wasted on this language.

robmccoll2• 12 years ago

Trolling or not, comment is unproductive. Might I suggest offering alternatives such as rehashing the "rust is arguably a better design with similar goals" vs "rust's library isn't as complete and the language isn't stable" debate?

I have been writing Go code professionally nearly every day for 6 months. Would I rather be writing C? Probably. Python? Not on a project of this scale. C++? Toss up. Java? No - doing far to much interfacing to C libs for that. Rust? Probably. Go is far from perfect, but honestly not that bad.

codygman4• 12 years ago

What advantages does Go have over Erlang?

kibwen2• 12 years ago

Comparing Rust to Go is equally unproductive, given that they target wildly different use cases and embody dramatically different philosophies. You might as well compare Lua to Objective-C, or OCaml to Malebolge.

howeyc• 12 years ago

I'm at the point where I hope they never add them, even though I've liked them in other languages.

Once they do, you know not every "generics or bust" will be satisfied and the anti-Go hate will simply shift.

I say let the haters hate and keep generics as their focal point.

pmr_• 12 years ago

So, you argue to not add a feature to the language because it would fix one of the main points of criticism? That is silly, don't you think?

sigzero2• 12 years ago

It is. The Go language devs should just own it and say "No". Will the arguments shift somewhere else? Maybe but maybe the "Go needs generics" folks will just go away.

coldtea17• 12 years ago

Once they do, you know not every "generics or bust" will be satisfied and the anti-Go hate will simply shift.

No, I don't know that.

Do you suggest they are lying and just hate go out of pure irrational emotion? (Despite some of the critics having writen thousands of lines in Go, or some like pjmlp have even had code in the standard libs).

Is there evidence to suggest that?

Does that hold true for other languages too? When people criticize a specific problem a language/technology has (e.g. Python's GIL or PHP's lack of proper language implementation with AST et al, SOAP for its verbosity, etc), is that out of "haters gonna hate" mentality?

Does that extend to that programmers cannot recognize constant pain points in a language, and those that complain about such things are irrational?

I find the idea expressed in the comment incoherent and illogical itself.

sacado24• 12 years ago

It's quite true, in fact. Look at Java's generics. Pre-Java 5, everybody was asking for generics. They got implemented. Now everybody complains they suck because they are a hack, they are slow, not that type-safe, made the language more complex, are not as powerful as C++/Ada/Haskell, etc. Nobody wants to go back to Java 4 (in which situation was worse than Go, tbh), but everybody (OK, most people) keeps complaining.

I'd myself be very happy with a hint of generics in Go, though. Something at the package level, that would be instantiated at "import" time (since the import keyword is supposed to hold some magic in itself) would have my preference.

qznc4• 12 years ago

There is only two ways to compile generics C++ (instantiation) and Java (type erasure) style. [0]

Alternatives to these are just manual or semi-manual variants. For example, Go people seem to like the "empty interface" approach. Well, that is Java-style type-erasure done manually. The code generation approach is just C++-style instantiation done outside of the compiler.

[0] http://beza1e1.tuxen.de/articles/generics.html

AndrewDucker2• 12 years ago

C# doesn't erase types, and it doesn't create a separate type for every possible variant.

See the ".Net Implementation" section here:

http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm...

pjmlp13• 12 years ago

This interview with Anders Hejlsberg is also a good source of information

http://www.artima.com/intv/generics.html

zwieback• 12 years ago

The .NET generics are also interesting to contrast with C++ and Java since they are implemented in a virtual machine that allows interoperation between different languages. Not really applicable to the Go discussion, though.

frowaway001• 12 years ago

Did you even read the article you linked to?

wheaties• 12 years ago

If they give us type safe c-like macros I will happily live without generics. This is from a Scala dev. I write Go because it's easier and less error prone than going through JNI. However the lack of any reasonable abstractions in Go makes it my last choice language.

AndrewDucker2• 12 years ago

What I find frustrating is that they seem to think that there are only two solutions - C++ (create a new type for each variant) or Java (erase the type information).

C# does it differently to either - see here:

http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm...

(The section marked ".NET Implementation")

Edit: And here's Anders Hejlsberg talking about the design:

http://www.artima.com/intv/generics.html

masklinn9• 12 years ago

What I find frustrating is that they seem to think that there are only two solutions - C++ (create a new type for each variant) or Java (erase the type information).

That, at least, is correct. Generics can be erased (compile-time only) or reified (generic type instances exist at runtime).

C# uses reified generics, and Mono creates (created?) a reification for each parameter typeset, Microsoft's implementation creates the same underlying reification for all reference types as a space optimisation, but it still uses reified generics.

There is a good helping of dishonesty in using C++ as the "reified generics" example though, as C++'s templates do significantly more than just reify generics (template specialisation, code generation, etc…) and that added to the interactions between templates and other language features makes them significantly more complex than e.g. C#'s, Rust's, Ceylon's, Kotlin's, and most other instances of reified generics.

tomp2• 12 years ago

Whether generics are erased or reified is orthogonal to how they are implemented (whether the code is specialized or not).

edgyswingset• 12 years ago

The argument brought up regarding compile times is also a misnomer. C#'s compiler pre-Roslyn is already very, very fast.

pjmlp13• 12 years ago

As usual, it lacks discussion about generics in:

- Eiffel

- Ada

- Modula-3

- D

- MLton

- .NET

- Rust

- Haskell

- OCaml

- Sather

- BETA

- CLU

Even if they overlap, it would be nice to see them being discussed. Not all generics are born alike.

Personally, I don't care any longer. It is still better than just plain C.

coldtea17• 12 years ago

That would be a great promo material:

Go: still better than just plain C.

Even beats Algol 68: http://cowlark.com/2009-11-15-go/

masklinn9• 12 years ago

Even beats Algol 68: http://cowlark.com/2009-11-15-go/

Isn't the point of the article that Go doesn't actually beat Algol 68?

The answer is that they're both very, very similar, with much the same level of functionality. They overlap more than they differ.
Go has more in the way of actual features --- interfaces, channels, maps, defer , fallthough , proper closures --- but Brand X is more consistent with its features. […]
Go, on the other hand, is full of corner cases. […]
Most killingly of all, it's full of examples where they did not consult the literature. […]
Brand X doesn't have any of these issues. Oh, it's got issues all of its own --- for example, the oddities in the reference type system; no varargs functions; no proper object system; the lack of little bits of syntactic sugar like keyworded composite structure literals... but it feels complete in a way that Go doesn't. I can use Brand X to implement nearly all the features of Go. I can't use Go to implement the features of Brand X.
The only major features that Go has that Brand X doesn't are proper closures, and the interface system. And I'm afraid that's not enough.
I would rather code in Brand X than Go.

josteink• 12 years ago

Go: still better than just plain C.

This seems to come up at every discussion about Go. What usually also comes up is how Rust is a much better designed language which solves real problems, while Go merely improves a little over C while leaving most of the same death-traps lying around.

Yet at the same time Go seems to have a much bigger adaptation than Rust. What's up with that? Are Googlers paid to create projects in Go, or are people genuinely happy to have anything which sucks less than C and stamped with a "final" badge of approval?

more_original• 12 years ago

Reminds me of Hoare's quote on ALGOL 60: "Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors."

jfaucett• 12 years ago

yes absolutely agree. Go is better than plain C, but people aren't using it for things C is used for which I think makes a big difference.

When it comes to developing software applications, the really weak type system of Go is frankly just causing developer pain. IMHO, generics are the missing feature in this language, just try writing a generic map or reduce function in Go and the amount of code you have to duplicate is ridiculous. Interfaces and using relection is not safe and annoying and having all the XXXInt, XXXFloat, XXXMyType is crazyness too.

For what its worth, my dream language would be Julia's type system grafted onto Go.

pjmlp13• 12 years ago

I moved on, and stayed on my comfy JVM/.NET/C++ world, but won't have any issues using it if a customer asks for a project on it.

borkadorka• 12 years ago

my dream language would be Julia's type system grafted onto Go

With Julia's type system you get a really good parametric multiple dispatch, which is a completely different (and more satisfying, to me) way to organize code than in Go. Go wouldn't be Go at all with Julia's type system.

If that's what you want, why not just program in Julia?

bluecalm2• 12 years ago

I just want to point out that C actually supports generics in a form of pointer to void.

masklinn9• 12 years ago

Casting to and from void pointers is very much not generics, and is in fact exactly what you have to do in Go (casting to and from `interface {}`) or pre-generics Java (casting to and from `Object`).

Although at least in Go and Java the downcast is checked and memory-safe, not so in C.

wtf_is_up• 12 years ago

interface{}

pjmlp13• 12 years ago

From that point of view, at least interface{} is type safe.

sacado24• 12 years ago

You'd have been right if you had said "C actually supports generics thanks to #define", but `void*` is the equivalent of interface{}

imanaccount2474• 12 years ago

It is still better than just plain C.

But without the speed of C. D and Rust are both better than C and better than go, while still being as fast as C (ok rust isn't always as fast as C yet, but it is still faster than go).

pjmlp13• 12 years ago

This is a compiler issue, don't mistake language with implementation.

In fact, gccgo does produce better code than the *g compilers

p0nce2• 12 years ago

More FUD and rationalizations from GhettoLang!

do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Easy I want "slow compilers and bloated binaries".

In my experience "bloated binaries" in the real world aren't as bad as one would think, since instruction cache problems only appear when your working set is huge, not when your total binary size is huge.

Equating big binaries with slowness is simply misleading. What's next, increased download times?

The generic structures are less useful than a concrete one.

Without generics you can't separate algorithms from data structures so everything is much less useful. If the members names are worse, sub-type then rename symbols.

Generic structures can be less optimized than a concrete solution.

False. That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template.

And type erasure is not a solution, it prevents inlining, constant folding and hoisting. Eg: In C++ std::vector<MyObject>::operator[] has 1 indirection, while using a generic C void* container would have 2. Guess which one is faster?

Generic algorithms can be less optimized than a concrete solution.

sigh

Also wrong since generics do not prevent specialization if needed. See: static if in D, template specialization in C++.

masklinn9• 12 years ago

In my experience "bloated binaries" in the real world aren't as bad as one would think, since instruction cache problems only appear when your working set is huge, not when your total binary size is huge.

The "bloated binaries" part is especially odd given the state of the Go compiler's optimisations (or lack thereof):

    $ cat >| test.go            
    package main
    func main() {}
    ^C
    $ go build test.go          
    $ wc -c test                      
      467008 test
    $ cat >| test.go                  
    package main
    import "fmt"
    func main() { fmt.Println("Hello, World!"); }
    ^C
    $ go build test.go          
    $ wc -c test                      
     1806192 test

egonelbre7• 12 years ago

Without generics you can't separate algorithms from data structures so everything is much less useful.

Generics is not the only way to separate data and algorithms. I agree that it is possible to sub-type/embed and rename - although looking at generic code, I rarely see that happen.

That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template.

When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem.

Basically, abstract things are harder to optimize for a particular case.

p0nce2• 12 years ago

Generics is not the only way to separate data and algorithms.

Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"?

When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case.

I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions.

robmccoll2• 12 years ago

Let's just use the C++ approach. Maybe with more restrictions to prevent abuse. Maybe not. To me the problems with C++ templates arise from their verbosity (Go's type system is rigid, but defining types is easy and encouraged and the compiler does inference for variable declarations), their abuse (let's keep it to simple type insertion), and the nasty errors / debugging (Go's type system rigidity should also help here).

Just being able to do very light type insertion and the transparent code generation to go along with it would go a long way.

karavelov• 12 years ago

I was considering Go for some project of mine but the lack of generics turned me away because the project needed to do some heavy numeric computations over custom containers (sparse matrices).

Now days I think that adding generics to Go will be disaster - Go lacks sound type system and piling generics on top of it will make the thinks even worse.

willvarfar• 12 years ago

In the pros for generic data-structures, it doesn't mention type-safety?!?!

tomp2• 12 years ago

Does anyone know how generics (for maps, slices, channels) are implemented currently in Go? Does it use type-specialization or boxing approach?

djhworld• 12 years ago

I find it amusing how angry people get about this, like really, vehemently angry.

If this issue is so important to people, don't use Go, use C++, Java, D or Rust. Don't waste your life arguing about something you'll never use, it's not a productive use of your time! Think about how much time you could save!

Alternatively, propose a solution to the problem and try and gain some traction to get it implemented into the language, or fork Go and implement it yourself. There's evidently a hunger out there for generics in Go, but everyone keeps assuming the responsibility lies with the Go Core team who's priorities seem (right now) to be in the optimising GC/compiler area.

personZ9• 12 years ago

This is exactly it. There are a lot of people who have argued passionately about this (the same crew of commentators appear with the same complaints in every single Go discussion), and now they are so deep in their advocacy that they feel their pride depends upon aggressively and vigorously defending it. It has gotten worse every time this has come up, and most of the comments are the logical conclusion. I mean seriously one of the comments calls it "ghettolang" without parody. Is this really Hacker News?

And exactly as you said -- for those people so offended by this: Move on. Use something different. Go isn't for you. As someone who has integrated Go very effectively into my life, I'm rather glad the Go team isn't listening to every railing fanatic and their pet issues.

coldtea17• 12 years ago

one of the comments calls it "ghettolang" without parody. Is this really Hacker News?

And then:

I'm rather glad the Go team isn't listening to every railing fanatic and their pet issues.

Oh, the irony.

Why people assume that only people NOT using Go are complaining, it's beyond me.

Or why people assume that if you like features X of a product, and would like it to have feature Y, you shouldn't.

marktangotango• 12 years ago

I was thinking this exactly. As an external observer (I don't use go, don't intend to. I do look to it as an interesting example language though) all the vitriol is very puzzling.

And you're right, the Go core team does not seem interested in adding generics anytime soon.

Personally, and this is my opinion, I find myself wondering if old school hackers like Thompson, Pike, and Fitzpatrick (and others) find themselves not needing generics, or that slice/maps are enough, maybe I should ponder that for a while. Ie do they know something I don't? Edit; or maybe the type of software they're creating with go is different than I as a generics user, am creating?

coldtea17• 12 years ago

or maybe the type of software they're creating with go is different than I as a generics user, am creating?

Or maybe their work is mostly creating Go, not using it, so they wouldn't care?

itg• 12 years ago

So should people stop talking about the pros/cons of programming languages at all? Because this can also go the other way. Another person can say: "If you enjoy programming in Go, then use it but keep quiet and stop promoting it and talking about how much you like it."

I haven't used Go at all yet, but I'm interested in hearing more about it the good and bad parts, along with other languages. Telling others to not complain at all doesn't do any favors.

tormeh• 12 years ago

I agree, but I think there's something to be said for not complaining about lack of generics in Go. We kinda got it the first 100 times it was said.

personZ9• 12 years ago

then use it but keep quiet and stop promoting it

Remarkably there has been close to zero promotion of Go on Hacker News. Occasionally various incremental update things appear on the front page, just as there are updates on C# 5, the next version of Java, etc, but there have been shockingly few "Why you should use Go" type posts.

People just use it. They don't advocate it. But when it comes up, inevitably it becomes an advocacy starting point for alternative languages. Somehow every single Go discussion, even about the most banal thing, ends up being about Rust, Haskell, F#, and so on.

lmm• 12 years ago

Koolaid point. Go is a much, much worse language than e.g. D, Rust, OCaml, but somehow it gets all this attention. I appreciate it's not productive, but you can see why this naturally makes people angry.

codygman4• 12 years ago

Perhaps the reason for anger is because of Go ignoring years of research and innovation. I would imagine people who were early adopters of power tools felt the same way.

Imagine if you were used to using power tools, but all the jobs available forced you to use hammers, screwdrivers, etc. Wouldn't this make you a little angry or at the very least disappointed?

diakritikal• 12 years ago

Sorry, but I can't see the value of posting this to hacker news. As evidenced by many people in this thread assuming it's from one of the core Go development team, it's not.

ominous_prime• 12 years ago

Exactly. This is one person's attempt to distill the previous conversations down to one document. It's not supposed to be justifying or rationalizing anything, nor does it speak for the core language contributors!

It's one person's summary of a very long and convoluted conversation. That's all.

egonelbre7• 12 years ago

Didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I made a mistake for not putting the "Draft" note at the top of the page in the first page.

I try my best to be objective - obviously this isn't easy. This is intended to be a review of both sides of the arguments. The generics discussion comes up again and again - I made this document to stop arguments going around in circles.

I will go over all the suggestions and add any missing information. Of course, if you have some good overview of some particular generics implementation you can PM me, or simply add that as a comment.

JulianMorrison• 12 years ago

Given "go generate", I actually think that code generation might be better. It's a more fussy mechanism, yes - but it's also a lot more general.

masklinn9• 12 years ago

1. Any old-timer Windows developer will tell you that statically generated code still has to be understood and maintained.

2. generics are about type-safety, not codegen. Codegen can be added on top of parametric polymorphism (e.g. C++ template specialisation), but is not required by any means (C# or Rust don't do any generic-based codegen beyond reification)

donatj• 12 years ago

To be fair I've not worked much in a languages that support generics but I assure you there are type safe solutions to most every problem without them (as long as you don't write yourself into a corner). Whether my life could be simpler using them is unseen but to say the lack of them cripples a language is wholly untrue. You're simply used to using them in your solution and are wired to think with them. That's a flaw in the developer, a lack of imagination, not a flaw in the language. Arguing every language needs every feature every other language has is stupid. "[lang1] is bad because it isn't [lang2]" Is always an infuriatingly stupid and pointless argument. Use lang2 if you love it so much. Seriously.

coldtea17• 12 years ago

That we can manually hack around this with busywork and tiptoe around the issue with various hacks doesn't mean it's not a flaw in the language.

It's 2014. Generics are a settled deal in programming languages. It's not some syntactic sugar or something the value of which is stull undecided and its advocates might "lack an imagination".

Use lang2 if you love it so much. Seriously.

Well, some do. That doesn't mean they don't get to complain about something they perceive broken in Go that could be better. Especially if they could use Go (to take advantage of other benefits it might have) if it weren't for those shortcomings.

In general, the statement is analogous to "if you have a problem with X in america, why don't you immigrate", which is silly. If you have a problem, you criticize, and you try to change that. You don't just dismiss everything that's also not problematic.

gnuvince• 12 years ago

The cons subsections that say that a generic version can be less optimized than a concrete version should mention which implementation is considered. If you use mono-morphization, then you end up with the same code as you would have written by hand, so there is no loss of performance there.

egonelbre7• 12 years ago

Abstract things are harder to optimize than concrete things. A package for a concrete problem can be more optimized than a generic/abstract package.

I don't mean that the manually specialized version is faster than automatically specialized template. Rather that this encourages to not write abstract data-types, but rather concrete types that solve a real world problem - editor.Buffer vs. gap.Buffer. Once you have a real world problem it can optimized much better for that use case.

jcadam• 12 years ago

As a language, I like Go. I would like it to have generics (Ada-style generic syntax might fit best). I don't care enough to get emotional about it. So, meh.

crawshaw• 12 years ago

For those who have not been following this discussion, I suggest reading this comment by Ian:

https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG...

pjmlp13• 12 years ago

Thanks for the link, Ian's comment is very interesting and goes into the direction I was stating in another post.

weberc24• 12 years ago

That's probably the best summary of the generics situation that I've seen to date. Thanks for sharing! :)

pcl• 12 years ago

(The Java approach.) Box everything implicitly.

Boxing and generics are orthogonal concepts.

Also: does auto-boxing even make sense in Go? Between the fact that Go is statically compiled and that there isn't an int / java.lang.Integer dichotomy to resolve, I would assume that the compiler could just do whatever it needed to with primitives, regardless of generics.

masklinn9• 12 years ago

Also: does auto-boxing even make sense in Go?

Yes, and already happens: interfaces cause wrapping of their content[0] and go does basic escape analysis and automatically allocates things which escape a function on the heap rather than the stack[1]

[0] https://golang.org/doc/faq#nil_error

[1] https://golang.org/doc/faq#stack_or_heap

Summary of Golang Generics Discussion

Related Stories