10 ms·

I completely agree with the author, though slightly surprised to see it come from the Go community, which has seemed like one of the more dogmatic languages. (

by bjt 10y ago

I completely agree with the author, though slightly surprised to see it come from the Go community, which has seemed like one of the more dogmatic languages. (E.g. all the "you don't need generics" arguments over the years.)

stanleydrew 10y ago
The author is implying that most of the "you don't need generics" arguments come from Go's users and not Go's creators. I don't have a good feel for whether that's true of the Go community, or maybe more importantly whether it's relatively more true of the Go community than, e.g., the Python community.
- zigzigzag 10y ago
  Arguments like "you don't need generics" or "exceptions lead to convoluted code" or "assertions are only used by lazy programmers" came from Go's creators. I too am rather surprised to see Go, Lisp and Haskell cited as languages designed by people who are not dogmatic. This may well be true at the micro-level of decisions like "how do you best compile green threads", but at the higher design levels all three languages are very, very opinionated. I think statement in particular is questionable: Contrast that kind of discussion with the heated arguments or overly zealous statements you sometimes see from users of the same languages. There's a real disconnect, possibly because the users don't have the experience of weighing the arguments on both sides and don't realize how easily a particular decision might have gone the other way. What is this implying? The designers of Go and Haskell never make "overly zealous statements" or "heated arguments"? Isn't the history of Go littered with such arguments, the most famous being that Go is simple because it's designed for Google engineers, who can't handle complex languages? It's definitely true that language communities are often zealous: when library interop is bad they have to be, in order to get an ecosystem of libraries and tools. That's why you see people posting things like "I made a terminal emulator in Rust" to Hacker News but don't see people posting the same for C++ or Java. Those languages have established ecosystems already and need much less evangelism.
  - weberc2 10y ago
    Being opinionated is pragmatic, not dogmatic. No successful carpenter uses a swiss army knife instead of a screw gun.
  - marcosdumay 10y ago
    Don't know about Go, but the one thing you don't see in the Haskell community is zealotry. Being opinionated is not the same as being dogmatic. Haskell developers have a clear position of letting features get in the language as the community pushes for, and the overall guidance is very much open to changes. The one thing you won't hear there is any equivalent of "generics are bad for you, we are not adding them".
    - yarrel 10y ago
      And Monads are like pizza.
      - marcosdumay 10y ago
        Donuts. Monads I can grasp, but never got how they are like donuts.
  - rhinoceraptor 10y ago
    Golang also has its own bespoke assembler, with unique syntax: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
  - grey-area 10y ago
    Strong opinions are not dogma as long as they are open to understanding the other options and change (as here). I think he's just trying to say that people should be less tribal and dogmatic about their tools, ,and users should try to understand that language design is about trade offs, not holy war. I think it is unhelpful to lump rsc in with rob pike, they are very different personalities.
- rhencke 10y ago
  For a year or so, I used to make minor contributions to the Go programming language codebase, back before it hit 1.0. That certainly by no means makes me an expert on it, nor do I claim to be someone of the caliber of Russ Cox or Rob Pike, but I did do a lot of reading on golang-dev and golang-nuts, before the language was settled on 1.0. There were a lot of discussions on generics, and the language authors and contributors were certainly open to ideas and indeed did their own fair share of research. For example, see https://research.swtch.com/generic https://research.swtch.com/generic from 2009. Indeed, the FAQ entry itself on Generics states 'Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.', and looking at the blame log, that's from 2010 or earlier, and it's stuck to this day. So, from everything I can see, the creators themselves are certainly open to the concept - I don't see any "you don't need generics" coming from that side.
  - stablemap 10y ago
    See also this document by Ian Lance Taylor, which links to his four attempts at generics: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
dmit 10y ago
If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo. Generics are not free, they bring a lot of baggage with them. And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all.
- coldtea 10y ago
  >If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?
  - dmit 10y ago
    >Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
    - coldtea 10y ago
      >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.
zalmoxes 10y ago
For context here is the author discussing Generics & Go: https://research.swtch.com/generic https://research.swtch.com/generic https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
woah 10y ago
I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. It's part of the bargain. Still, if you really feel passionately that Go with generics would be frickin' awesome, generics seem like a pretty easy thing to write a preprocessor for. With the great knowledge of programming language design and implementation that most pro-go-generics internet forum posters have, it should be a piece of cake.
- weberc2 10y ago
  I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.
- nemo1618 10y ago
  >generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.
  - rtegx 10y ago
    Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
    - camus2 10y ago
      http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
    - nemo1618 10y ago
      Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.
weberc2 10y ago
In my experience, the defenses for Go's stance on generics seem to be more nuanced than the criticisms. The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated. On the other hand, many of the criticisms of Go amount to "Go is unusable because it lacks generics". YMMV.
- chimeracoder 10y ago
  > The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated The general consensus from the Go developers is probably best summarized as "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." Which isn't to say that Go will never see generics, if someone finds the right way to implement them.
  - sanderjd 10y ago
    > "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." I think what people tend to disagree with is the last part. There is a lot of leeway in estimating the costs and benefits and people end up with very different estimates.
cicero 10y ago
I am not a Go user, but I've been following it from the beginning. What I've observed is that since one of its design principles is simplicity, it left out features that many people think are essential for a modern programming language. This results in a lot of criticism of the language which provokes a defensive reaction that might overstate their position. The truth is that one does not need generics. I've worked for decades in languages that don't have generics. The real question is with current software capabilities and requirements, is the convenience provided by adding generics to Go worth the cost of the added complexity. People clearly disagree, and the language designers decided "no". That's not dogma; that's engineering.
- camus2 10y ago
  > The truth is that one does not need generics. Sure ,when you can use interface {} AKA void pointers everywhere, you certainly don't need generics /s You need generics if you want to avoid context.Context.Value(interface {})interface {} like API. You need generics if your goal is type safety AT COMPILE TIME. Obviously it's not one of the goals of Go /s ...
  - dmit 10y ago
    Here is an illuminating (to me) post that shows how the Go approach to solving algorithmic problems might be different from other languages (in this case, a generic graph data type + Dijkstra's algorithm): https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztx... Sure, the final implementation still has a couple instances of interface{}, but they are much more innocuous than your example.
  - randomdata 10y ago
    Out of curiosity, how would you avoid `Context.Value(interface{}) interface{}` with generics? The net/context package was designed to pass request lifetime context throughout your service infrastructure (think microservices), where the values provide metadata from your transport protocol. HTTP headers, if we want to think in terms of HTTP, although obviously there is no specific protocol dependency at this layer. The value may not even be assigned by a Go program, so it seems that runtime validation would be a necessity even with generics. A broken or malicious program upstream could easily inject something into the context that you weren't expecting, or simply not supply the value at all.
__david__ 10y ago
I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can tell, in that direction, only dogma lies.
- hodgesrm 10y ago
  I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.
  - __david__ 10y ago
    My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own unique style, and while I think it's good for a project to use a consistent style, using it across every project seems dumb. Cross-project style consistency doesn't buy us anything reasonable--there's no "engineering" about it. Also, braces around conditional logic isn't what I'm talking about here (since that's not a "go fmt" style choice--that's the language syntax).
    - hodgesrm 10y ago
      This is likely to be controversial but code conventions are like GOTO statements for me--it seems best to adopt baked-in formatting conventions so that it's no longer possible to waste time and energy arguing about them. Also, it avoids the exertion of chasing people who don't do it consistently and mess up merges or ability to see diffs. Finally, it eliminates the bad feelings that result from religious arguments about code formatting. Most project teams have limited resources to come up with a solution that is close enough to correct to make the project pay off. In new technology there also tends to be a small set of technical issues that are hard and that you must get right--nothing else matters that much if you fail on the core. I am pretty heartless about anticipating things like code conventions, security requirements, legal review, etc. and just following the rules or otherwise making them non-issues for the project team in areas where it does not fundamentally alter the outcome. Edit: clarification
zaphar 10y ago
The Go core team has been opinionated but not really dogmatic. Their argument has never been that you don't need generics. It has been we don't want to add them in the currently available forms right now and here are the ways you can get around their absence in the meantime.
- candiodari 10y ago
  And therefore soon we'll get a repeat of the JDK 1.5 generics disaster and many compatibility caveats.
  - zaphar 10y ago
    Or maybe they won't go the generics route and instead you'll get code generation as a first class citizen.
deleted 10y ago
[deleted]

by bjt 10y ago

stanleydrew 10y ago

The author is implying that most of the "you don't need generics" arguments come from Go's users and not Go's creators. I don't have a good feel for whether that's true of the Go community, or maybe more importantly whether it's relatively more true of the Go community than, e.g., the Python community.

zigzigzag 10y ago
Arguments like "you don't need generics" or "exceptions lead to convoluted code" or "assertions are only used by lazy programmers" came from Go's creators. I too am rather surprised to see Go, Lisp and Haskell cited as languages designed by people who are not dogmatic. This may well be true at the micro-level of decisions like "how do you best compile green threads", but at the higher design levels all three languages are very, very opinionated. I think statement in particular is questionable: Contrast that kind of discussion with the heated arguments or overly zealous statements you sometimes see from users of the same languages. There's a real disconnect, possibly because the users don't have the experience of weighing the arguments on both sides and don't realize how easily a particular decision might have gone the other way. What is this implying? The designers of Go and Haskell never make "overly zealous statements" or "heated arguments"? Isn't the history of Go littered with such arguments, the most famous being that Go is simple because it's designed for Google engineers, who can't handle complex languages? It's definitely true that language communities are often zealous: when library interop is bad they have to be, in order to get an ecosystem of libraries and tools. That's why you see people posting things like "I made a terminal emulator in Rust" to Hacker News but don't see people posting the same for C++ or Java. Those languages have established ecosystems already and need much less evangelism.
- weberc2 10y ago
  Being opinionated is pragmatic, not dogmatic. No successful carpenter uses a swiss army knife instead of a screw gun.
- marcosdumay 10y ago
  Don't know about Go, but the one thing you don't see in the Haskell community is zealotry. Being opinionated is not the same as being dogmatic. Haskell developers have a clear position of letting features get in the language as the community pushes for, and the overall guidance is very much open to changes. The one thing you won't hear there is any equivalent of "generics are bad for you, we are not adding them".
  - yarrel 10y ago
    And Monads are like pizza.
    - marcosdumay 10y ago
      Donuts. Monads I can grasp, but never got how they are like donuts.
- rhinoceraptor 10y ago
  Golang also has its own bespoke assembler, with unique syntax: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
- grey-area 10y ago
  Strong opinions are not dogma as long as they are open to understanding the other options and change (as here). I think he's just trying to say that people should be less tribal and dogmatic about their tools, ,and users should try to understand that language design is about trade offs, not holy war. I think it is unhelpful to lump rsc in with rob pike, they are very different personalities.
rhencke 10y ago
For a year or so, I used to make minor contributions to the Go programming language codebase, back before it hit 1.0. That certainly by no means makes me an expert on it, nor do I claim to be someone of the caliber of Russ Cox or Rob Pike, but I did do a lot of reading on golang-dev and golang-nuts, before the language was settled on 1.0. There were a lot of discussions on generics, and the language authors and contributors were certainly open to ideas and indeed did their own fair share of research. For example, see https://research.swtch.com/generic https://research.swtch.com/generic from 2009. Indeed, the FAQ entry itself on Generics states 'Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.', and looking at the blame log, that's from 2010 or earlier, and it's stuck to this day. So, from everything I can see, the creators themselves are certainly open to the concept - I don't see any "you don't need generics" coming from that side.
- stablemap 10y ago
  See also this document by Ian Lance Taylor, which links to his four attempts at generics: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...

dmit 10y ago

If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo. Generics are not free, they bring a lot of baggage with them. And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all.

coldtea 10y ago
>If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?
- dmit 10y ago
  >Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
  - coldtea 10y ago
    >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.

zalmoxes 10y ago

For context here is the author discussing Generics & Go: https://research.swtch.com/generic https://research.swtch.com/generic https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417

woah 10y ago

I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. It's part of the bargain. Still, if you really feel passionately that Go with generics would be frickin' awesome, generics seem like a pretty easy thing to write a preprocessor for. With the great knowledge of programming language design and implementation that most pro-go-generics internet forum posters have, it should be a piece of cake.

weberc2 10y ago
I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.
nemo1618 10y ago
>generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.
- rtegx 10y ago
  Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
  - camus2 10y ago
    http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
  - nemo1618 10y ago
    Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.

weberc2 10y ago

In my experience, the defenses for Go's stance on generics seem to be more nuanced than the criticisms. The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated. On the other hand, many of the criticisms of Go amount to "Go is unusable because it lacks generics". YMMV.

chimeracoder 10y ago
> The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated The general consensus from the Go developers is probably best summarized as "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." Which isn't to say that Go will never see generics, if someone finds the right way to implement them.
- sanderjd 10y ago
  > "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." I think what people tend to disagree with is the last part. There is a lot of leeway in estimating the costs and benefits and people end up with very different estimates.

cicero 10y ago

I am not a Go user, but I've been following it from the beginning. What I've observed is that since one of its design principles is simplicity, it left out features that many people think are essential for a modern programming language. This results in a lot of criticism of the language which provokes a defensive reaction that might overstate their position. The truth is that one does not need generics. I've worked for decades in languages that don't have generics. The real question is with current software capabilities and requirements, is the convenience provided by adding generics to Go worth the cost of the added complexity. People clearly disagree, and the language designers decided "no". That's not dogma; that's engineering.

camus2 10y ago
> The truth is that one does not need generics. Sure ,when you can use interface {} AKA void pointers everywhere, you certainly don't need generics /s You need generics if you want to avoid context.Context.Value(interface {})interface {} like API. You need generics if your goal is type safety AT COMPILE TIME. Obviously it's not one of the goals of Go /s ...
- dmit 10y ago
  Here is an illuminating (to me) post that shows how the Go approach to solving algorithmic problems might be different from other languages (in this case, a generic graph data type + Dijkstra's algorithm): https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztx... Sure, the final implementation still has a couple instances of interface{}, but they are much more innocuous than your example.
- randomdata 10y ago
  Out of curiosity, how would you avoid `Context.Value(interface{}) interface{}` with generics? The net/context package was designed to pass request lifetime context throughout your service infrastructure (think microservices), where the values provide metadata from your transport protocol. HTTP headers, if we want to think in terms of HTTP, although obviously there is no specific protocol dependency at this layer. The value may not even be assigned by a Go program, so it seems that runtime validation would be a necessity even with generics. A broken or malicious program upstream could easily inject something into the context that you weren't expecting, or simply not supply the value at all.

__david__ 10y ago

I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can tell, in that direction, only dogma lies.

hodgesrm 10y ago
I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.
- __david__ 10y ago
  My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own unique style, and while I think it's good for a project to use a consistent style, using it across every project seems dumb. Cross-project style consistency doesn't buy us anything reasonable--there's no "engineering" about it. Also, braces around conditional logic isn't what I'm talking about here (since that's not a "go fmt" style choice--that's the language syntax).
  - hodgesrm 10y ago
    This is likely to be controversial but code conventions are like GOTO statements for me--it seems best to adopt baked-in formatting conventions so that it's no longer possible to waste time and energy arguing about them. Also, it avoids the exertion of chasing people who don't do it consistently and mess up merges or ability to see diffs. Finally, it eliminates the bad feelings that result from religious arguments about code formatting. Most project teams have limited resources to come up with a solution that is close enough to correct to make the project pay off. In new technology there also tends to be a small set of technical issues that are hard and that you must get right--nothing else matters that much if you fail on the core. I am pretty heartless about anticipating things like code conventions, security requirements, legal review, etc. and just following the rules or otherwise making them non-issues for the project team in areas where it does not fundamentally alter the outcome. Edit: clarification

zaphar 10y ago

The Go core team has been opinionated but not really dogmatic. Their argument has never been that you don't need generics. It has been we don't want to add them in the currently available forms right now and here are the ways you can get around their absence in the meantime.

candiodari 10y ago
And therefore soon we'll get a repeat of the JDK 1.5 generics disaster and many compatibility caveats.
- zaphar 10y ago
  Or maybe they won't go the generics route and instead you'll get code generation as a first class citizen.

deleted 10y ago

[deleted]