18 ms·
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. The
by 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 agoIt doesn't appear we are waiting longer to get a better solution, rather we appear to be waiting and getting no solution.
- rsc 10y agoTelling those two apart reliably is one of the fundamental problems in computer science.
- sreque 10y agoJust 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 agoI 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 agoWasn'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?