8 ms·

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 g

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.

jpgvm 12y ago
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?
- mrcwinn 12y ago
  "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.
  - jpgvm 12y ago
    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.
    - NateDad 12y ago
      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.
mijoharas 12y ago
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.
deleted 12y ago
[deleted]
pdpi 12y ago
> 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.
- mhd 12y ago
  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).
- ascotan 12y ago
  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.
  - frowaway001 12y ago
    So how are you writing Go if you neither use arrays/slices, maps, channels, etc.?
- scott_s 12y ago
  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.
laumars 12y ago
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.
- jerf 12y ago
  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....)
  - laumars 12y ago
    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).
    - jerf 12y ago
      "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.
emmelaich 12y ago
But fast compilation is one of the major raisons d'être of Go.
fishnchips 12y ago
> 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.
bane 12y ago
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.
- twoodfin 12y ago
  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.
- dvirsky 12y ago
  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.
- scott_s 12y ago
  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.
  - bane 12y ago
    Yeah, I think you're right. Didn't quite a few early C++ compilers just generate intermediate C code that was then compiled down?
    - scott_s 12y ago
      I'm not sure about quite a few, but the first one did - Cfront, implemented by Stroustrup.
GFK_of_xmaspast 12y ago
"I don't understand why they bother." Evangelism.
dllthomas 12y ago
"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.
- dragonwriter 12y ago
  > 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.
  - NateDad 12y ago
    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 https://tour.golang.org/basics/7
copsarebastards 12y ago
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 http://rationalwiki.org/wiki/Balance_fallacy

jpgvm 12y ago

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?

mrcwinn 12y ago
"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.
- jpgvm 12y ago
  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.
  - NateDad 12y ago
    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.

mijoharas 12y ago

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.

deleted 12y ago

[deleted]

pdpi 12y ago

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

mhd 12y ago
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).
ascotan 12y ago
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.
- frowaway001 12y ago
  So how are you writing Go if you neither use arrays/slices, maps, channels, etc.?
scott_s 12y ago
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.

laumars 12y ago

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.

jerf 12y ago
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....)
- laumars 12y ago
  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).
  - jerf 12y ago
    "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.

emmelaich 12y ago

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

fishnchips 12y ago

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

bane 12y ago

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.

twoodfin 12y ago
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.
dvirsky 12y ago
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.
scott_s 12y ago
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.
- bane 12y ago
  Yeah, I think you're right. Didn't quite a few early C++ compilers just generate intermediate C code that was then compiled down?
  - scott_s 12y ago
    I'm not sure about quite a few, but the first one did - Cfront, implemented by Stroustrup.

GFK_of_xmaspast 12y ago

"I don't understand why they bother." Evangelism.

dllthomas 12y ago

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

dragonwriter 12y ago
> 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.
- NateDad 12y ago
  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 https://tour.golang.org/basics/7

copsarebastards 12y ago

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 http://rationalwiki.org/wiki/Balance_fallacy