5 ms·

FWIW, generics were added to Java in 2004, about 9 years after initial release. ref: https://en.wikipedia.org/wiki/Generics_in_Java https://en.wikipedia.org/wi

FWIW, generics were added to Java in 2004, about 9 years after initial release. ref: https://en.wikipedia.org/wiki/Generics_in_Java https://en.wikipedia.org/wiki/Generics_in_Java

vvanders 10y ago
Since they were tacked on they also have all sorts of issues like type erasure and the like that make them a pain to use in certain cases.
whatever_dude 10y ago
And one could say it was too early. Under the hood, generics are pretty bad in Java [0]. Type information is mostly lost; it's a compiler time only feature. They're much better implemented in C#, even if they look the same on the surface, probably because it came later and they took it seriously. So I applaud the Go architects with being conservative about it. More languages should take their time thinking about implementing features, no matter how needed they seem to be initially. You only get one chance, and then if it's a bad choice you live with the consequences. [0] http://www.jprl.com/Blog/archive/development/2007/Aug-31.html http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm...
- tonyedgecombe 10y ago
  It doesn't appear we are waiting longer to get a better solution, rather we appear to be waiting and getting no solution.
  - rsc 10y ago
    Telling those two apart reliably is one of the fundamental problems in computer science.
- sreque 10y ago
  Just about every programming language expert I've seen who's talked about Java generics says Java did a better job than C#. In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. Examples of runtimes that do not specialize or reify generics: * JVM * Haskell runtime * ML family of languages * Modula-3 * Ada The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with. Type erasure, for instance, makes it much easier to implement alternative languages on the JVM such as JRuby, Clojure, Scala, or Kotlin, than on .NET. As another example, C# in 4.0 added the concept of generic type variance, which is completely at odds with specialized generics. To implement this feature, the C# language designers had to modify the underlying runtime itself and add special bytecode instructions for the feature. The feature itself is also incompatible with specialized generics, so when you use it you silently lose specialization. In contrast, thanks to type erasure, the Scala language designers could easily add the same feature on top of the JVM as-is without needing Oracle to add special bytecode instructions. Specialization has advantages for performance when doing number crunching with data structures and algorithms operating directly on integral or floating point data types. At the end of the day, though, if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways. It takes an incredible amount of effort to build a data structure or algorithm that is both generic and also performant in all possible usage scenarios. It is however, much easier to build a data structure or algorithm that is specific and performant relative to your use case alone. Case in point: when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance.
  - josefx 10y ago
    > In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. As a C++ programmer I would mention templates as something similar. > The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with. When inheritance comes in to play Java ends up storing generic type information in the child classes. It even has to generate bridge methods since Runtime does not really deal with int compareTo( Comparable<? extends T> ) vs. int compareTo ( MyInteger ) . > if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways An ArrayList<Integer> makes sense in very few cases and is extremely slow, 64 bit pointers to objects that contain useless metadata and a immutable 32 bit int. Sadly an IntList is neither generic nor is it compatible with anything that operates on List<T>s, which results in duplication of a lot of algorithms just to sort primitives. > when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance. Case in point: In C++ std::vector<double> and the standard algorithm header take care of most of that. If there is some specialized implementation of some algorithm for double values then you can still use that without copy pasting the implementation of everything else.
    - sreque 10y ago
      I purposely left out templates because I do not consider them to be the same as generics. Their is no "runtime" support for templates; templates are basically a glorified macro engine for creating new code based on type parameters. But yes, templates by definition specialize since they are creating new code every time they are instantiated.
      - josefx 10y ago
        > Their is no "runtime" support for templates; At runtime any Java List is a list of Objects, you cannot distinguish an ArrayList<Integer> from an ArrayList<Double> both are a raw ArrayList. What runtime support do they have? > I feel bad for the C++ linkers that have to sift through all the template bloat to dedupe them :(. If you have a template used often enough you can declare it extern and force instanciation in a specific cpp file.
- MichaelGG 10y ago
  Wasn't it too late? I thought the reason they went the type erasure path was because they didn't want to take the compat hit of changing the bytecode that much. Is that not accurate? Maybe if they had done generics originally it'd have been built in to the runtime. Isn't this potentially going to happen in Java10 or something?
coldtea 10y ago
So? Java doesn't have channels either (except in third party libs added much later), but they were in Go from the start. Same for e.g. plain structs, which Java will only now acquire. When one language added a feature has no bearing to when another should add it.
- crypto5 10y ago
  > So? Java doesn't have channels either (except in third party libs added much later), but they were in Go from the start. Channels is specific concurrency paradigm. Java utilizes others, not less powerful.
camus2 10y ago
FWIW Go is almost 8 years old now, and there is absolutely no plan to implement generics in anyway right now. I think they just can't without breaking backward and forward compatibility, they should just admit it instead of trying to avoid the question.

FWIW, generics were added to Java in 2004, about 9 years after initial release. ref: https://en.wikipedia.org/wiki/Generics_in_Java https://en.wikipedia.org/wiki/Generics_in_Java

vvanders 10y ago

Since they were tacked on they also have all sorts of issues like type erasure and the like that make them a pain to use in certain cases.

whatever_dude 10y ago

And one could say it was too early. Under the hood, generics are pretty bad in Java [0]. Type information is mostly lost; it's a compiler time only feature. They're much better implemented in C#, even if they look the same on the surface, probably because it came later and they took it seriously. So I applaud the Go architects with being conservative about it. More languages should take their time thinking about implementing features, no matter how needed they seem to be initially. You only get one chance, and then if it's a bad choice you live with the consequences. [0] http://www.jprl.com/Blog/archive/development/2007/Aug-31.html http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm...

tonyedgecombe 10y ago
It doesn't appear we are waiting longer to get a better solution, rather we appear to be waiting and getting no solution.
- rsc 10y ago
  Telling those two apart reliably is one of the fundamental problems in computer science.
sreque 10y ago
Just about every programming language expert I've seen who's talked about Java generics says Java did a better job than C#. In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. Examples of runtimes that do not specialize or reify generics: * JVM * Haskell runtime * ML family of languages * Modula-3 * Ada The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with. Type erasure, for instance, makes it much easier to implement alternative languages on the JVM such as JRuby, Clojure, Scala, or Kotlin, than on .NET. As another example, C# in 4.0 added the concept of generic type variance, which is completely at odds with specialized generics. To implement this feature, the C# language designers had to modify the underlying runtime itself and add special bytecode instructions for the feature. The feature itself is also incompatible with specialized generics, so when you use it you silently lose specialization. In contrast, thanks to type erasure, the Scala language designers could easily add the same feature on top of the JVM as-is without needing Oracle to add special bytecode instructions. Specialization has advantages for performance when doing number crunching with data structures and algorithms operating directly on integral or floating point data types. At the end of the day, though, if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways. It takes an incredible amount of effort to build a data structure or algorithm that is both generic and also performant in all possible usage scenarios. It is however, much easier to build a data structure or algorithm that is specific and performant relative to your use case alone. Case in point: when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance.
- josefx 10y ago
  > In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. As a C++ programmer I would mention templates as something similar. > The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with. When inheritance comes in to play Java ends up storing generic type information in the child classes. It even has to generate bridge methods since Runtime does not really deal with int compareTo( Comparable<? extends T> ) vs. int compareTo ( MyInteger ) . > if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways An ArrayList<Integer> makes sense in very few cases and is extremely slow, 64 bit pointers to objects that contain useless metadata and a immutable 32 bit int. Sadly an IntList is neither generic nor is it compatible with anything that operates on List<T>s, which results in duplication of a lot of algorithms just to sort primitives. > when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance. Case in point: In C++ std::vector<double> and the standard algorithm header take care of most of that. If there is some specialized implementation of some algorithm for double values then you can still use that without copy pasting the implementation of everything else.
  - sreque 10y ago
    I purposely left out templates because I do not consider them to be the same as generics. Their is no "runtime" support for templates; templates are basically a glorified macro engine for creating new code based on type parameters. But yes, templates by definition specialize since they are creating new code every time they are instantiated.
    - josefx 10y ago
      > Their is no "runtime" support for templates; At runtime any Java List is a list of Objects, you cannot distinguish an ArrayList<Integer> from an ArrayList<Double> both are a raw ArrayList. What runtime support do they have? > I feel bad for the C++ linkers that have to sift through all the template bloat to dedupe them :(. If you have a template used often enough you can declare it extern and force instanciation in a specific cpp file.
MichaelGG 10y ago
Wasn't it too late? I thought the reason they went the type erasure path was because they didn't want to take the compat hit of changing the bytecode that much. Is that not accurate? Maybe if they had done generics originally it'd have been built in to the runtime. Isn't this potentially going to happen in Java10 or something?

coldtea 10y ago

So? Java doesn't have channels either (except in third party libs added much later), but they were in Go from the start. Same for e.g. plain structs, which Java will only now acquire. When one language added a feature has no bearing to when another should add it.

crypto5 10y ago
> So? Java doesn't have channels either (except in third party libs added much later), but they were in Go from the start. Channels is specific concurrency paradigm. Java utilizes others, not less powerful.

camus2 10y ago

FWIW Go is almost 8 years old now, and there is absolutely no plan to implement generics in anyway right now. I think they just can't without breaking backward and forward compatibility, they should just admit it instead of trying to avoid the question.