4 ms·

C# got rid of type erasure and is better for it. Java really needs to bite the bullet and do the same. It is just a compatibility hack anyway.

by lnanek2 12y ago

alkonaut 12y ago
I have tried to make that point but usually I'm told it's impossible ir unnecessary. a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>. Obviously, this would be a half-assed solution unless custom value types like point structs would also be allowed without boxing in similar scenarios. I'm not sure but I think that these things need pretty significant changes to the runtime. My conclusion is that Java doesn't need this. It won't be elegant no matter what amount of lipstick is added. I even think some of the current features like lambdas are overkill. Instead, features should be added at the vm level to allow for other jvm langs to use them. A good functional language with good generics over primitives and proper value types would be awesome. F# is a good example of such a language (scala and clojure aren't)
- pron 12y ago
  The work is already underway in Project Valhalla: http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/ Once it's been decided Java should get value types, generic reification became a more urgent necessity.
  - alkonaut 12y ago
    Interesting. Curious to see if they choose exactly the same approach to e.g. value types as the CLR and C# teams did. In C# it feels like there are very few places where choices could have been made differently. Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation.
    - pron 12y ago
      Java's value types will be immutable, while in C# I believe structs are mutable. This is a very important difference with serious implications to concurrency. > Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation. The tradeoffs are often not what you think they are.
      - alkonaut 12y ago
        Mutable structs in c# are rare, rarely useful and often dangerous, but in some perf critical scenarios that hack is needed. Most notably the standard List<T>.Enumerator is a mutable struct because othrrwise an object would have to be created on the heap for the sole purpose of iterating a list. Not sure whether this was actually one of the reasons for allowing mutable structs to begin with, the use case is critical enough that it might well have been.
    - moomin 12y ago
      You can in C#. You can also do tricks like allocating large struct arrays for stuff that 100% isn't going to need to be garbage collected.
      - alkonaut 12y ago
        Yes and you do things in Java like create an MyIntCollection to get around the shortcomings of generics wrt. primitives, but the point is that it is just that: workarounds. What I really want is for perf to be good while the code is still clean/readable/expressive/idiomatic. In Java/C# you must usually write idiomatic+slow and then refactor into fast kludges.
        ygra 12y ago
        I'd say that's always the case. Performance for the vast majority of code is good enough with idiomatic or even horrible code. Places where you need to work against the language for perf reasons should be rare (and if it concerns most of the code in a project, then I'd question the choice of language for that project). Also that holds true for most languages. Even in C you'll avoid allocations in tight loops that need to be fast because it comes with an unpredictable performance cost. That's not much different than pre-allocating a buffer to work on prior to an algorithm in C#.
- jdmichal 12y ago
  > a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>. This is actually pretty much exactly what the .NET runtime does. All value types get a separately-JIT'd version of the type, while all reference types share the same Object-based version. See section on implementation here: http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).aspx#csharp_generics_topic2 http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).as...
deleted 12y ago
[deleted]

C# got rid of type erasure and is better for it. Java really needs to bite the bullet and do the same. It is just a compatibility hack anyway.

by lnanek2 12y ago

C# got rid of type erasure and is better for it. Java really needs to bite the bullet and do the same. It is just a compatibility hack anyway.

alkonaut 12y ago

I have tried to make that point but usually I'm told it's impossible ir unnecessary. a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>. Obviously, this would be a half-assed solution unless custom value types like point structs would also be allowed without boxing in similar scenarios. I'm not sure but I think that these things need pretty significant changes to the runtime. My conclusion is that Java doesn't need this. It won't be elegant no matter what amount of lipstick is added. I even think some of the current features like lambdas are overkill. Instead, features should be added at the vm level to allow for other jvm langs to use them. A good functional language with good generics over primitives and proper value types would be awesome. F# is a good example of such a language (scala and clojure aren't)

pron 12y ago
The work is already underway in Project Valhalla: http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/ Once it's been decided Java should get value types, generic reification became a more urgent necessity.
- alkonaut 12y ago
  Interesting. Curious to see if they choose exactly the same approach to e.g. value types as the CLR and C# teams did. In C# it feels like there are very few places where choices could have been made differently. Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation.
  - pron 12y ago
    Java's value types will be immutable, while in C# I believe structs are mutable. This is a very important difference with serious implications to concurrency. > Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation. The tradeoffs are often not what you think they are.
    - alkonaut 12y ago
      Mutable structs in c# are rare, rarely useful and often dangerous, but in some perf critical scenarios that hack is needed. Most notably the standard List<T>.Enumerator is a mutable struct because othrrwise an object would have to be created on the heap for the sole purpose of iterating a list. Not sure whether this was actually one of the reasons for allowing mutable structs to begin with, the use case is critical enough that it might well have been.
  - moomin 12y ago
    You can in C#. You can also do tricks like allocating large struct arrays for stuff that 100% isn't going to need to be garbage collected.
    - alkonaut 12y ago
      Yes and you do things in Java like create an MyIntCollection to get around the shortcomings of generics wrt. primitives, but the point is that it is just that: workarounds. What I really want is for perf to be good while the code is still clean/readable/expressive/idiomatic. In Java/C# you must usually write idiomatic+slow and then refactor into fast kludges.
      - ygra 12y ago
        I'd say that's always the case. Performance for the vast majority of code is good enough with idiomatic or even horrible code. Places where you need to work against the language for perf reasons should be rare (and if it concerns most of the code in a project, then I'd question the choice of language for that project). Also that holds true for most languages. Even in C you'll avoid allocations in tight loops that need to be fast because it comes with an unpredictable performance cost. That's not much different than pre-allocating a buffer to work on prior to an algorithm in C#.
jdmichal 12y ago
> a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>. This is actually pretty much exactly what the .NET runtime does. All value types get a separately-JIT'd version of the type, while all reference types share the same Object-based version. See section on implementation here: http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).aspx#csharp_generics_topic2 http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).as...

deleted 12y ago

[deleted]