Summary of Go Generics Discussions | Hacker News Reader

Summary of Go Generics Discussions

docs.google.com

55 pointsscapbi83 comments

This is such a biased document as to be pointless. The authors are so opposed to generics that I don't understand why they bother. Just a few beauties:

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

I don't think these are the only outcomes, but lets go with it. A slightly slower compiler then. Solved.

> The generic structures are less useful than a concrete one.

If they weren't more useful then nobody would be arguing for them.

> Generic structures can be less optimized than a concrete solution

Ridiculous.

>Code won’t look idiomatic.

Idiomatic is a function of the language syntax and features. If generics are a feature then their use will, by definition, be idiomatic.

And on and on. At this point people using Go accept the lack of generics (and, oddly, sometimes wear the omission as a badge of honor). I don't think anyone happily using Go is expecting generics anytime soon, if at all. And I don't think the authors need a paper to show their dislike for them. Who are they trying to convince anyway?

EDIT: A few folks have told me I come across too heavy handed in my reply. I apologize to and don't mean to discourage the author(s)! It's a tough document to write. Especially if this was just a starting "brain dump." The document title had just set my expectation towards a neutral tone.

I agree.

Those using Go without generics will go on using it.

I would also posit the following though:

Those that don't use Go because it lacks things like generics aren't likely to use it once they are added either.

My personal opinion is Go is a simple language with little to no features of significance. This makes it easy to learn and easy to write. However, it leaves programmers used to higher level and more powerful constructs wanting. If you are used to writing Haskell or even something like Ruby then Go is going to feel like a pretty significant step down. God forbid you are looking at a language like Rust which makes Go look skinny in terms of features indeed.

At the end of the day it boils down to what you are happy with using. Is a hammer and nails good enough for you? Or do you prefer a variable speed handheld drill with impact mode and keyless chuck, etc etc etc?

"God forbid you are looking at a language like Rust which makes Go look skinny in terms of features indeed."

No disrespect meant to Rust, but it's hardly as simple as saying, "Go lacks Generics! Use Rust!" Rust is far --- far --- from production-worthy. It's certainly settling down into a 1.0, but it has had an extremely volatile standard library and design. There are some early contributors who are doing the "brave work" of using it in production with the aim of bringing it forward to a 1.0, but for the rest of us, it's simply not even in the consideration set.

There's also a real question about garbage collection. Rust's "feature set" is surely thicker than Go's - but you need some of those things because you're doing much more work at compile-time. We can argue about the runtime cost of a mature GC (and Go isn't even there yet!), but again, it's not as simple as "use Rust." There's a real productivity cost, I would argue, with doing that extra work and adding that complexity.

It doesn't boil down only to what you are happy with using. For the weekend project, it really doesn't matter at all. For a large, production application, there are real, important questions to answer and they matter a great deal. It's not "is a hammer good enough?" - A hammer is hardly good enough when you're staring at screws.

I'm not saying one is right or one is wrong. I'm saying choosing a language is usually only something that matters at a certain scale, and at that scale, you have to be very knowledgable and careful.

I wasn't saying someone should use Rust over Go because of Traits and other generic programming features.

I was saying if you are evaluating Rust then Go probably looks very feature light in comparison.

Same goes for programmers currently using Java/C# or even Haskell. Go is just a lot less featured than other high performance managed languages that are just as battle tested and just as fast.

This is not to say that it's not a good language or the correct tool for a job. Only that those programmers will be left wanting in many areas, generics only being one.

People who use Java and C# actually have a lot fewer reasons not to use go. The lack of a required runtime applies to both, better cross platform compatibility then C#, and lower memory overhead and faster startup than Java... You lose generics but you gain real value types and better concurrency primitives.

I can't believe how they're actually using "Built-in generic types, i.e. the current Go approach (generic types map/chan/slice)" as an argument AGAINST generics. I mean this is unbelievable. Of course that list is not complete, as there are more generic datatypes in Go (arrays, function return value-tuples, ...).

Fact is, the golang authors are using generics (and polymorphism, and ...) in the language and in the compiler. So they have answered all the questions about generics :

> does it result in a slow compiler ?

Obviously not, after all the compiler has generics.

> are generic structures less useful ?

Well how useful do the Go authors find map/slice/arrays/... the generic Go datatypes ? So obviously this is both a bullshit argument and one people like Rob Pike don't actually believe is true.

> Generic structures are less optimized

If this is true, then clearly Go's authors find this an acceptable cost.

More generally, let's take a look at Rob Pike's example code. For instance here is a talk described as "An hour-long talk delivered by Rob Pike at Google in October 2009. The language's first public introduction."

http://talks.golang.org/2009/go_talk-20091030.pdf

First code example that isn't hello world, first function called :

  if len(str) > 0 { ch = str[0] }

A polymorphic function ...

  weekend := []string{ "Saturday", "Sunday" }

  timeZones := map[string]TZ {
    "UTC":UTC, "EST":EST, "CST":CST, //...
  }

Generic data types.

Why are we arguing about this ? There is no disagreement between Go's users and authors : Go needs generics. The authors simply don't feel capable of implementing it.

How about, like hundred other problems in Go we simply ask ourselves "is this hard to program in a compiler ?", and yes it is. So they put in an ugly hack for their own special cases. This argument, first of all, consistently fits all Go languge decisions leading to the correct conclusion, as opposed to all the arguments given by the Go authors that have no end of exceptions and personal preferences to take into account to arrive at the correct conclusion. Go's authors clearly have some trouble understanding the mathematical foundations of type systems, which is plainly visible in Go's type system. It's inconsistent. Without massive holes in the language, like we currently, this will become VERY visible and move people away from Go.

Shame you were downvoted as it definitely added to the conversation.

That said I would disagree that flaws in a type system will result in people moving away from Go. Scala has a type system that is ridiculous complex and has plenty of holes and it doesn't seem to have affected its adoption rate.

He was down voted because he is saying that anyone who disagrees with his opinions is unintelligent.

>"Go's authors clearly have some trouble understanding the mathematical foundations of type systems"

Well, yeah. Is there anything wrong with that?

Why assume they don't understand instead of assuming they do, and chose to use something more simple? Especially when simplicity is an explicit goal of the language.

This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc

For these developers Go can be a good fit. Everybody knows it doesn't have feature parity with Haskell et al from a computer science perspective.

If that's all that mattered we would be seeing a lot of Haskell adoption wouldn't we?

You shouldn't pick a language based on a checklist.

>This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc

All of which are orthogonal to having a more modern language, except maybe simplicity.

And even for that, after a while you understand that not having, say, generics, pattern matching or some such language feature, is not "simpler" is just having to do more busywork manually and in an error prone way.

There's simplicity as in "this is simple to understand and use" and simplicity as in "we ommited some advanced functionality and you'll have to built it by yourself, every time". The second is a false simplicity.

As Einstein put it: "we should make things as simple as possible, but not simpler".

Pointing to a specific point were making something simpler makes it lose the essense it should have.

It is simpler. It's like comparing English to German. Sure, in German you can just say "schadenfreude" and in English you have to say "taking joy from someone else's misfortune", but everyone will understand the latter, and many people may misunderstand the former... And even though you may feel smarter for being able to use a big word, if you are writing a legal document that needs to be understood by many people, you're probably better off with the more wordy English.

>but everyone will understand the latter, and many people may misunderstand the former...

And the analogy breaks in that all German speakers will understand the former.

> There's simplicity as in "this is simple to understand and use"

Yeah, it's a known fallacy. We should replace "simplicity" and "readability" with understandability, since we don't really care about the first two, but only confuse people.

Ease of deployment: the first and hardest deployment step is creating code worth deploying.

Readability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less readable than generics, not more readable.

Compile time: this is an overblown concern. If you're using a compilation system that compiles only the parts you change, your typical compilation should be so quick as to take negligible time. Complete rebuilds such as on a CI server should be happening asynchronously to development and therefore should only cost server time, which is of negligible value in comparison with development time. If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation).

Language simplicity: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less simple than generics, not more simple.

Toolchain simplicity: I am not able rightly to apprehend the kind of confusion of ideas that could provoke someone to think this is relevant.

Maintainability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less maintainable than generics, not more maintainable.

Before you dismiss compile time as "an overblown concern", I recommend reading Rob Pike's paper version of his talk, "Language Design in the Service of Software Engineering" (http://talks.golang.org/2012/splash.article).

In particular, take a look at section 5, "Dependencies in C and C++." From that section:

The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte.

As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries.

The consequence of these uncontrolled dependencies and massive scale is that it is impractical to build Google server binaries on a single computer, so a large distributed compilation system was created. With this system, involving many machines, much caching, and much complexity (the build system is a large program in its own right), builds at Google are practical, if still cumbersome.

I think that Pike makes a convincing case that fast compile times at scale are a reasonable requirement for their needs.

Compile times are an overblown concern, not because compile times don't matter, but because generics don't equate to long compile times. Two things:

1. Talking about C++ doesn't prove anything about the effects of generics on compilation time. C++ doesn't have generics, it has templates. Also, C++ is a particularly difficult language to compile quickly--it shouldn't be hard to compile a language faster than C++, even if you completely ignore templates/generics. If you want to make a reasonable comparison to Go's compilation, you should be looking at Java or C#. I've worked on an 800,000 line Java project and a 500,000 line C# project (the second made very heavy use of generics). The first took about two hours to build completely from scratch, the second, 40 minutes (both on not-particularly-powerful desktop workstations--the difference in time also is affected by the fact that there was 5 years between these projects). And like I said, typical builds of only changed code took <30 seconds.

2. I already said this, so I'll just quote myself: "If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation)." 4.2 megabytes of code means that no one can reason effectively about the system, especially in a language as dense as C++.

I think it is unfair to call this document biased, from the document:

> This document is a distillation of convoluted generics discussions and it is not an official opinion of the Go team, although it does incorporate their opinions.

I think the document simply amalgamates all the points that have been made on both sides of the debate. I would agree that some of the points made against the generics do seem to be somewhat biased (or debatable or flimsy/whatever), but I think the document itself merely tries to collect all of these arguments together, so that when someone says, "what is the argument against this point?", people can point to this document and say that someone raised the argument that "The generic structures are less useful than a concrete one". I think then that can be used as the starting point for discussion (someone can raise the counterpoint that they think this is wrong).

I see this as separating the discussion of the validity of the points from an enumeration of the points made so that people can refer to them (which I think is helpful). In addition, with all the arguments for and against collected together, people can more effectively discuss the proposition.

EDIT: I am all for go having generics, I just don't think the document itself is biased.

> I don't think these are the only outcomes, but lets go with it. A slightly slower compiler then. Solved.

Except that a capital-F Fast compiler is a design goal for the language, so that's the _least_ desirable of the three. I feel tempted to go with slower execution times, simply because it's already a part of the design as well: you can't optimise too aggressively on a limited compilation time budget.

Who says that "slower" doesn't still remain within the realm of "fast", perhaps even with a capital F?

I wouldn't assume that the language as is is totally devoid of features that already complicate compilation -- that would probably result in some kind of polish notation proto pascal…

So it's all about tradeoffs, and the go designers just say that this isn't worth it, at least for the current time and the current Plan9-ish Thompson compiler. Whether this crosses over from the pragmatic to the dogmatic is up for discussion (cf. dynamic linking).

Generics are a nice feature to avoid code duplication. However, they are not required to be used in every application. Whatever the solution is, it should not affect code that doesn't require the use of generics. If the entire language is affected (such as a slower runtime because of the need to box/unbox) that would be a step down.

So how are you writing Go if you neither use arrays/slices, maps, channels, etc.?

That the compiler will be slower can be used as an argument against any new language feature. Slightly slower would, I think, still mesh with their design goals. But slower, and the amount of slowdown is a function of the number generics used in a module, or in a total application, might not mesh with their goal.

Basically, I'm saying that if we're going to talk about compiler performance - and we should, since as you point out, it is a design goal of Go - we need to be a bit more concrete. Based on everything I know about Go's goals, they would be particularly worried about solutions that don't scale.

And if the additional compilation time is not perceptible ?

Seems like a pretty stupid approach to ignore any language additions if they have any potential to impact the design goals. Implement it. Benchmark it. Then decide if it should be landed into mainline builds.

>Except that a capital-F Fast compiler is a design goal for the language, so that's the _least_ desirable of the three.

Except the compiler is nothing to write home about in the "fast" department (others, including D are just as fast), and modular compiling and a good design of linking etc can solve the compile speed issue far better, and without sacrificing more important things...

Besides, this only means they don't understand diminishing returns and opportunity cost.

It often amazes me that Go wasn't given some level of generics from the offset since it's a web-focused language and the web is untyped.

If I'm honest though, most of the time I don't miss generics. However the moment I start using a database or parsing JSON documents (particularly ones you cannot make assumptions about the document structure), the lack of generics is a massive pain.

It actually was given "some level" of generics; arrays and maps are generic (or at least more generic than anything else), but they're programmed as special cases into the syntax and runtime rather than as an instance of generic generic (ahem) functionality.

This is part of why the Go generic debate rages on, while Go itself is continuing to be used. If Go were lacking in any "generic" associative lookup structure it would get no traction in 201x. (If C were introduced today in a world that somehow lacked it, nobody would give it a second look. Which is as it should be... one would hope we've learned something in the past 40 years....)

I don't really think it's fair to argue arrays as an example of generics since they've been around since the dawn imperative programming languages and have been a staple in the kinds of languages that people example as having a lack of generics.

I'd also question whether maps are a good example either since a map[string]interface{} would be incompatible with a map[int]interface{} (which leads to many of the code duplication examples that developers demonstrate when discussing the need for generics in Go)

Maybe I'm splitting hairs, but this would likely be the mindset that Pike et al have with regards to "generic" built in types.

I do agree with you that there is "some level" of generics on Go though: interfaces{}. Sadly that feature was "uglified" by the constant need for casting (and that's putting it politely).

"I'd also question whether maps are a good example either since a map[string]interface{} would be incompatible with a map[int]interface{}"

The map is what is generic, not a specific map. List<Int> is not "compatible" with a List<Char> in any implementation of generics; how could it be? What would that even mean?

There isn't a good way of taking a "map", just any "map", but that's a separate problem. Not all languages that have generics can do that, either, only some of them.

(A recurring issue in these discussions about Go is that people end up bringing the union of all possible things that generics have ever done, anywhere, to the party, but in reality no language actually has all of those features at once. Real generic implementations, when not being discussed in the context of Go, are usually being discussed in how they are broken. This is what ultimately brought me peace in this argument... in the abstract, it's totally obvious that Go ought to have generics. In the concrete it's a great deal less obvious, and real implementations all do indeed have their serious problems once you get down to the nitty-gritty of what assembly instructions they would actually execute, and exactly how the compiler would produce them. It's all fun and games when you're just waving hands around.)

interface{} isn't a "generic" in any sense.

> The map is what is generic, not a specific map. List<Int> is not "compatible" with a List<Char> in any implementation of generics; how could it be? What would that even mean?

Well, arguably there are languages where that's possible. PHP does some odd things with maps and arrays, and Perl hashes don't have any distinctions between strings, integers nor floats (or at least none that I've run into - please correct me if I'm wrong). Though I will grant you that I'm now comparing strongly typed languages to weakly typed ones.

I think my problem here is although I cut my teeth on statically typed languages, my exposure to generics in those languages was rather limited (in fact does Pascal even support generics?). So I'm possibly misunderstanding the usage of generics in modern strongly typed languages.

It's web focused?

In 2015, your new language needs to have some web stuff built into the standard library or at least some foundation libraries. I don't know that that makes it web focused though.

Seems like there is a huge cultural gap or something, Go was initially built by real-deal C guys. There is a ton of overlap with them and like the plan-9 and suckless fans. If you're not doing hard-realtime or poking registers, it very very much looks like a language designed to fix the problems C has. Just about any of the standard UNIX tools could fairly easily be built in Go and probably be cleaner, maybe more bug free. When the go compiler and run-times are optimized up and the performance is there, it seems like you'd really need a compelling argument to not write those kinds of tools in Go instead of C. If you really dive in to the plan-9 and suckless stuff, how many of those programs legitimately have more than a couple data-structures? They are small, they do one thing, they try to do it well. There are a lot of "missing" things that they aren't urgent the replace because of that, like dynamic linking...

What's really amazing is that it has been drawing the ruby, js and python guys in. And generics is a/"The Big" hangup? Why not just the fact that you actually have to compile it or that the compiled product has an OS and hardware requirement.

>It's web focused?

Web-focused is a poor choice of words on my part. But IIRC Google adopted the project as a means to speed up development and execution time for their web services back ends (if that's wrong then I'll happily welcome a correction).

Either way, Go does have a presence in web development - not least of all by Google

> What's really amazing is that it has been drawing the ruby, js and python guys in. And generics is a/"The Big" hangup? Why not just the fact that you actually have to compile it or that the compiled product has an OS and hardware requirement.

Only the compiled binary is OS dependant, the code is just as portable as your exampled languages. And the only hardware requirement is the word size and architecture of the CPU - which for web development would nearly always be x86_64. Plus Go makes cross-compiling child's play - so there's no issues with compiling for another CPU architecture (if, for some reason, you're targeting ARM over x86) or for 32bit platforms, Windows, FreeBSD, OS X or Linux.

I actually think the fact that Go needs compiling is a real strength of Go. Unit and regression testing of websites can be painful in JIT compiled, dynamic languages; where as go build catches a lot of developer "absent-mindedness" before the web application even reaches the testing phase. Obviously compiling isn't going to catch everything, but in my experience, it has massively streamlined the process of developing production ready code.

But fast compilation is one of the major raisons d'être of Go.

> I don't think anyone happily using Go is expecting generics anytime soon, if at all.

I certainly do. Go replaced Ruby as my language of choice some three years ago but the lack of generics have often prevented me from properly reusing existing code. I would totally love to see (ideally Haskell-like) generics introduced, the sooner the better.

The solution of course is for somebody to build a precompiler that lets people write generics, then compiles down their code into go code -- generating all the necessary type-specific code along the way.

Lots of people don't remember this, but there used to be a whole host of such tools in the early Java days when the language was more terrible than it is now. IIR there's a bunch of similar stuff for C as well.

I guess a modern analog would be something like CoffeeScript which fixes all sorts of issues with Javascript.

We could call it go++!

More seriously, this would make sense as a prototyping step (I think the Java equivalent was called Pizza?), but ultimately this would be a fork of the language, with all that implies.

There already exist such tools, and especially now with go-generate in 1.4 it's become easier to do that. But we need deeper integration for them, like gocode completion being able to work on the generic files, linters that can lint a template based source file, etc. If a holistic approach like that would exist I'd personally use a preprocessor.

That's identical to what they call the C++ approach, except it's just not part of the actual language. I don't think that's an attractive solution.

Yeah, I think you're right. Didn't quite a few early C++ compilers just generate intermediate C code that was then compiled down?

I'm not sure about quite a few, but the first one did - Cfront, implemented by Stroustrup.

There's already tools in Go for meta-programming. In fact coincidentally I was reading about a few of these tools earlier today [1][2][3] - but personally I don't like that approach.

[1] http://www.slideshare.net/wuvist1/metaprogramming-go-with-py...

[2] https://github.com/pquerna/ffjson

[3] http://blog.golang.org/generate

"I don't understand why they bother."

Evangelism.

"If generics are a feature then their use will, by definition, be idiomatic."

I'd agree, but for the "by definition". "Idiomatic" is a question of typical patterns of use. This is "a function of the language syntax and features", but that function is not a simple or static one and involves the programming community around the language. It's certainly possible for a feature to fall out of favor and its use to be unidiomatic.

> I'd agree, but for the "by definition". "Idiomatic" is a question of typical patterns of use. This is "a function of the language syntax and features", but that function is not a simple or static one and involves the programming community around the language. It's certainly possible for a feature to fall out of favor and its use to be unidiomatic.

For example, Ruby for loops are part of the language, but there use is pretty universally considered unidiomatic.

Even in a small, young language like go, there are already features that are considered somewhat unidiomatic, like naked returns: https://tour.golang.org/basics/7

I agree with others who have said this document isn't biased. I think it has a different problem: balance fallacy[1]. It's putting two opinions next to each other as if they were both equally worth considering.

If, in an interview, someone wrote Java code using ArrayList instead of ArrayList<T> or C# code using List instead of List<T>, I wouldn't hire that person. If you write code in Java or C# that doesn't use generics, you're giving up type safety, performance, readability, reusability... the list goes on. Your code is bad and you should feel bad.

Not having generics in Go means that your code will be less type-safe, less performant, less readable, less reusable, etc. than comparable code in Java or C#.

I'll go one step further and say it was short-sighted for the Go developers to implement data structures without generics in the first place. Yes, it makes it harder to implement the language initially, but that's an up-front investment of time that will prevent millions of lines of bad code from being written if the language gains traction. Users who really insist on shooting themselves in the foot can do GenericType<Object> and make their bad decision explicit. It's just bad design for a modern statically-typed language not to include generics (or a comparably powerful type abstraction).

[1] http://rationalwiki.org/wiki/Balance_fallacy

> No abstract examples/arguments. These cause the discussion to lose focus and make examples harder to follow. The example/argument must be traceable to a real-world problem - Go is intended to solve real problems not imaginary ones.

I find that's a very good rule in those discussions, it's too easy to get bogged down to some obscure use case and miss the forest for the trees.

I note however that the authors seemed to have forgotten about that rule just after writing it down since the rest of the document is full of vague assertions and unsubstantiated arguments like:

- "I have heard of simple libraries having text segments shrink from megabytes to tens of kilobytes by revising or eliminating the use of templates."

- "Generic algorithms can be harder to follow than their non-generic counterparts."

- "Fancy algorithms are slow when n is small, and n is usually small. - Rob Pike"

- "map/slice suffice for most of the cases encountered in programming. (based on some community opinions https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG.... The linked thread contains a bunch of posts, not sure what I should be looking for (I thought the whole point of this document was to "go over the relevant points without digging through hundreds of forum posts"?)

- "Code won’t look idiomatic." I'm not sure what that even means.

I don't know if generics have a place in Go or not but I'm not sure this document is going to help solve that issue. Making a list of concrete use cases for generics and discussing possible alternatives would probably be more constructive.

"I note however that the authors seemed to have forgotten about that rule just after writing it down..."

I feel I need to remind you, and a lot of the other commenters here, that this is a top-level summary of all the various arguments. And that it is possible on the Internet to mention arguments without actually advocating for them at the same time. I doubt you could find any individual on the planet that would "agree" with that entire document from top to bottom.

Then it should link to the various places where those arguments have been discussed. As it is it's hard to take that as a neutral reference and looks more like an opinion piece against the implementation of generics in Go trying to pass off as a neutral reference. If that was on wikipedia it would be littered with [citation needed].

I get that, but I had the same reaction as simias. I, and I assume simias as well, is not concerned with the advocacy, but the lack of examples. I read the introduction and thought "Oh, cool! I'll get to see lots of use-cases showing how things behave in various circumstances." But I mostly saw the same hand-wavy arguments I see elsewhere.

I think the better reaction to simias and my point is that this is clearly a work in progress. I assume that in the future, it will actually contain the use-cases I thought it would.

Previous discussion: https://news.ycombinator.com/item?id=8756683

Something that has turned into such a contentious topic one would think someone would fork the project to add generics themselves. Perhaps in an effort to "prove" how it could be done easily or cleanly.

How many man-hours have been spent arguing about this?

I've actually considered stabbing at it, but at the moment it's best to wait for the idiomatic Go rewrite of the compiler to get further along.

And by "stabbing at it" I mean opening up the compiler to see how difficult it would be, not a commitment. But even for that, the best answer right now is to wait for the in-progress compiler rewrite to get further along.

I think it will be interesting to see what kinds of things bloom from the rewrite of the compiler.

From the java section:

> A vector of bytes uses significantly more than one byte per byte.

There is still the option to use an array of bytes (the primitive data type, not the class Byte) if the performance of boxing/unboxing is a problem.

In fact, i don't understand how the vector example is relevant to generics at all. Even pre-generics the underlying storage for a Vector in java would be an Object array so the boxing/unboxing would still happen?

Ah, this threw me for a while too. So the answer appears to be: Suppose you have a generic function X(Y), where the "Y" is generic. Now suppose you want Y to be truly generic, and not just Java-style generic, which means that Y may be any size. That is, it may be a "byte", it may be "short", a "long", a 184-byte struct, a pointer, etc etc etc. The way most programming languages do functions, functions encode into themselves the sizes of what they are expecting, and the expectation for how they are going to receive parameters. Therefore, a single function can't take all those options, and at the very least you end up needing one per base size, plus one for spilling to the stack... and that's just to deal with the size issue, you still have signedness, various struct properties if you're passing structs, etc.

So one option is to "box" everything, which basically amounts to saying "I will take a pointer to everything", and in the case of Go, "I will take the pointer to that thing's type". (That's how interfaces work in Go.) Now everything is the same size (pointer-sized). But now everything's boxed. Alternatively, you can compile lots of functions, but now everything's compiled in separate copies of the function.

From the high-level language POV it all seems so simple. When converting it into actual assembly, which has to interact with the rest of the system, it gets more complicated, and the performance implications of even slight slowdowns to a function call can be catastrophic given how many of them we make.

Personally I'm still interested in the question of whether it's feasible to create a different calling convention into a generic function that deals with this directly. This might not be possible in C due to its age, or C++ due to its reverse-compatibility heritage, but I'm interested in whether we can write a sufficiently-generic (in the more general sense of the term) function calling system that it can work with Go better. Basically looking at types like a vtable and abstracting out all the calls that are size-dependent into vtable-lookups, which ought to be slower but only slightly slower than a direct call (given that it seems like everything can be resolved at compile time except the actual address). But I don't know. Interested to hear if anybody else has ever tried that or anything similar. (Assembler is a great deal more flexible than the structured programming we have laid on top of it, at least in theory.)

Thank you, that was a great explanation.

For what i've been using java for it's never really bothered me. When there is need to use primitives it's almost always in the form of a list where you can just use an array instead to avoid the boxing/unboxing.

The risk of null pointer exceptions when implicitly unboxing objects are more annoying..

The Go team has repeatedly stated they have nothing against generics per se and they see a value for it. They simply have not found an implementation that works with language values (simplicity, fast compilation, etc.)

If anyone can come up with an implementation that works, I see no reason why the team would say no to its inclusion.

/offtopic

This kind of discussion is actually something that bothers me even more than generics at the moment : https://groups.google.com/forum/#!topic/golang-nuts/m7k9Epxq...

Come on... removing an item from a list requires tricks ?? I know go aims at being memory efficient, but delete(list,obj) should be idiomatic.

Come on... removing an item from a list requires tricks ??

That's not a list, it is a slice. Which is a slight abstraction over an array. You the programmer are directly responsible for the size of the slice storage, and how many elements it currently contains.

I know go aims at being memory efficient, but delete(list,obj) should be idiomatic.

If this ends up being a common operation, I could understand arguments to add it to the language. But in general if you are adding / removing items a lot, you'd be better off using an actual list data structure instead.

Then i guess we're back to generics. Having to use this interface :

http://golang.org/pkg/container/list/ , with its "Element" wrapping a "Value" property of type interface{} seems really weird for such a basic need. It means that whenever you're storing an object into the list, you need to remember the element in addition to the original object to be able to remove it later...

Except that no one ever actually used that package. We just use normal slices which are generic.

Hence my point... People use arrays like they would use ArrayList or Vector or any dynamic container created in the last 25 years and expect to be able to remove an object in one function call.

And people use lists like they would an array and assume a list of 100 int64s uses 800 bytes, when it actually probably uses twice that much (if you're lucky).

I'm not a Go programmer, but I think this is a problem of data structure expectations. Slices are not "lists", but views into arrays. So, by design, slices are a view into contiguous chunks of values. In such structures, removing an item will necessarily be O(n).

A general principle in interface design for data structures is don't make expensive things easy. So, if removal from a slice is O(n), then the data structure is obviously not optimized for that, so don't provide a function for it.

+1 this is exactly it.

I would agree, except for the fact that slices have a lot of very convenient sugar syntax, making it look like the de facto standard for storing anything (with maps that is).

Well, i may be spoiled, but ever since i stopped working with C, i never had to deal with data structure so different between arrays and list than go (that is, slices and container/list).

The performance concern is an absolute hypocrisies. Whenever you decide which structure you pick in eg, Java, you know that the various containers are optimized for various operation, and you decide which to use depending on performance only.

In go the language is so broken (because of the type system) that using a chained list vs an array makes your code look completely different.

Seems you're looking for SliceTricks from the Go wiki: https://code.google.com/p/go-wiki/wiki/SliceTricks

Actually there are multiple options for delete from a slice. If you need to preserve order then it's going to be an O(n) operation, and if you're deleting often maybe it shouldn't be a slice but some other structure. There are two options for delete mentioned in that document:

Delete

    copy(a[i:], a[i+1:])
    a[len(a)-1] = nil // or the zero value of T
    a = a[:len(a)-1]

Delete without preserving order

    a[i], a[len(a)-1], a = a[len(a)-1], nil, a[:len(a)-1]

That generics would allow for better Type-safety is only true if one compares it to using empty interfaces (or some other type less thing).

But it would actually lead to less accurate Type-safety than if one had a different sort method for each sortable type, it would lead to some amount of "duplicated" code but that is a different matter than Type-Safty.

It would lead to less safety but more type safety, actually.

http://jspha.com/posts/six_points_about_type_safety/

It is incorrect to say that the c approach is no generics. C has its precompiler macros which functionally provide a crude form of generics.

C macros are the worst form of macros. They are string substitution without type checking and can very easily leaf to all sorts of issues. That said I'm in the macros camp instead of generics just because I think go authors would actually do it.

Hygienic macros for Go (i.e. an equivalent of sweet.js http://sweetjs.org/) would be very interesting.

If you're rooting for language features based on the willingness of your language designers to implement them rather than what will make the language better, your language ecosystem is fundamentally broken and it's time to move on.

Preprocessor-based solutions (and cleaner, IIRC, than C preprocessor macros) for Go generics exist, too. So, "no generics" for C is as accurate as "no generics" for the Go status quo.

"exist" is not the same as "is built into the language and compiler".

Neither C nor Go has generics, preprocessor based or otherwise, built into the language and compiler.

Both C and Go can have (and, in fact, it has been done in both) some degree of generics implemented in a preprocessor-based way using only features built into the language and compiler.

So, again, I would maintain that "no generics" is no more valid of the Go status quo than it is of the C status quo.

C's macros are a form of code generation. In context, generics is parametric polymorphism[0] which does not imply code generation, though it can be extended to support it (template specialisation). Parametric polymorphism is about static type-safety.

[0] http://en.wikipedia.org/wiki/Parametric_polymorphism

I wonder what a survey of real Go users about generics would show. I'm betting an overwhelming majority would like that.

Would these be people writing "production" code in Go who need generics, and for some reason have not been instead using a language with the features they need?

The whole continued argument is odd. The "whole generics are important" and "Go is too simple" thing seems counterintuitive when all of the comments mention Rust, Haskell, Java, etc., yet the proponents of generics are not using those languages instead.

Why if Go does not have the features one needs, would a person be compelled to use it?

Simple - it has many other virtues that outweigh this even if you need it.

I'm writing a lot of production Go code, and I'm very happy about the language. I wouldn't put generics at the top of my wish list but at times I wish I had them. But not enough that I'm willing to use a 3rd party solution, so I guess not that much :)

It's pretty well split down the middle from my experience on these topics. And few people are really ravenous for them. However, you're talking about selection bias. If generics were something you absolutely wanted, you probably wouldn't be using go in production.

One of the things you learn when using go is that generics are not the answer to everything. They are certainly the answer to some specific things, like optimal implementations of common algorithms.... But not every application needs to use the A* algorithm, or a left leaning red black tree... Would I like to have generic implementations of those that I could just toss in my application with my own types? Sure. But I've done enough generic programming to remember when you could finally stop writing

    foo<bar<baz, bat> >

And could finally do

    foo<bar<baz, bat>>

.... And I don't really want to have to write that kind of code again.

Reply on news.ycombinator.com