4 ms·

> .NET has both of them I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard,

by pron 8y ago

> .NET has both of them I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard, in exchange for a rather slight added convenience. This means that if you're a language implementor and you're targeting .NET, you'll get much less from the platform than you would if you target Java, which makes .NET not a very appealing common language runtime. And not only is Java a good platform for Kotlin and Clojure, but thanks to Truffle/Graal it's becoming a very attractive, and highly competitive, platform for Ruby, Python and JavaScript. All of that would have been much more difficult with reified generics. Also, I don't think value types in Java are being "pushed back." The team is investing a lot of work into them as it's a huge project, but AFAIK no timeline has been announced. > and also has the same core strengths JVM does I don't think so. Its compilers are not as good, its GCs are not nearly as good, and its production profiling is certainly not as good (have you seen what JFR can do?); and its tooling and ecosystem are not even in the same ballpark.

bunderbunder 8y ago
I see it as a double-edged sword. On the one hand, reified generics means that it's .NET's object model or the highway. On the other hand, .NET maintains a much higher standard of inter-language interoperability. When I was on .NET, I didn't have to worry much about the folks working in F# accidentally rendering their module unusable from C#. Now that I'm on the JVM, I've accepted that it's just a given that the dependency arrows between the Java and Scala modules should only ever point in one direction.
- pron 8y ago
  It's not .NET vs Java so much that the development of the two languages you mention are coordinated. For Kotlin and Clojure interop works both ways; Scala doesn't care much about that, so Scala developers write special facades as Java language API. There are lots of different languages on Java, and they care about different things. The Java team itself develops only one language, although at one time there was another (JavaFX Script). Some language developers (Kotlin, JRuby) work more closely with the Java team, and others (Scala) hardly ever do.
gliop 8y ago
Is a value type different from a value class? https://github.com/google/auto/blob/master/value/userguide/index.md https://github.com/google/auto/blob/master/value/userguide/i...
- dbaupp 8y ago
  Yes, those value classes are still heap/GC allocated objects. Value types are a generalisation of `int`, `long`, `float` (etc), where values are stored inline, not allocated on the heap. For instance, a `Pair<long, double>` that isn't a pointer, but is instead the exactly the size of a long plus a double, and is the same as writing `long first; double second;` inline.
sporkland 8y ago
Dumb question. Why do reified generics make interop challenging? Or is it reified generics plus value types that don't inherit system.Object? Couldn't the language implementations basically pass around ICollection<Object> in .NET somewhat similar to how they do in Java?
- munchbunny 8y ago
  The problem is that your GenericClass<T1> and GenericClass<T2> are really more like GenericClass_T1 and GenericClass_T2 with their own distinct type definitions and interfaces. From the perspective of a different runtime/language trying to interop with these types, you have to somehow understand and work with this mapping game. It's much easier from inside the .NET runtime than outside. The general solution is, like you suggested, to avoid using reified generics in the module interface where the interop happens.
  - bunderbunder 8y ago
    The solution I remember from the last time I dealt with Python on .NET (which was admittedly a long time ago) was the opposite - you did use the reified generics, and there were facilities to create an instance of GenericClass<TWhatever> from within Python. There's a whole dynamic language runtime that is purpose-built for smoothing over a lot of that stuff. What wouldn't work would be to, e.g., create a Python-native list and try to pass it into a function that expects a .NET IList<T>. Which doesn't feel that odd to me - they may have the same name, but otherwise they're very different types that have very different interfaces. That said, the Iron languages never took off. My personal story there is that all the new dynamic features that C# got with the release of the DLR pretty much killed my desire to interact with C# from a dynamic language. The release that gave me Python on .NET also turned C# itself into an acceptable enough Python for my needs.
- pron 8y ago
  > Why do reified generics make interop challenging? Suppose you have types A and B, such that A <: B. What is, then, the relationship between List<A> and List<B>? This question is called variance, and different languages have very different answers to this, but once generics are reified, the chosen variance strategy is baked into the runtime. > Couldn't the language implementations basically pass around ICollection<Object> in .NET somewhat similar to how they do in Java? They could, but then this adds significant runtime overhead at the interop layer. For example, a popular standard API may take a parameter of type List<int>. How do you then call it from, say, JavaScript, without an O(n) operation (and without changing JS)?
datavirtue 8y ago
The user is what matters. As a language user I want reified generics. Don't care what the implementers want.

by pron 8y ago

bunderbunder 8y ago

I see it as a double-edged sword. On the one hand, reified generics means that it's .NET's object model or the highway. On the other hand, .NET maintains a much higher standard of inter-language interoperability. When I was on .NET, I didn't have to worry much about the folks working in F# accidentally rendering their module unusable from C#. Now that I'm on the JVM, I've accepted that it's just a given that the dependency arrows between the Java and Scala modules should only ever point in one direction.

pron 8y ago
It's not .NET vs Java so much that the development of the two languages you mention are coordinated. For Kotlin and Clojure interop works both ways; Scala doesn't care much about that, so Scala developers write special facades as Java language API. There are lots of different languages on Java, and they care about different things. The Java team itself develops only one language, although at one time there was another (JavaFX Script). Some language developers (Kotlin, JRuby) work more closely with the Java team, and others (Scala) hardly ever do.

gliop 8y ago

Is a value type different from a value class? https://github.com/google/auto/blob/master/value/userguide/index.md https://github.com/google/auto/blob/master/value/userguide/i...

dbaupp 8y ago
Yes, those value classes are still heap/GC allocated objects. Value types are a generalisation of `int`, `long`, `float` (etc), where values are stored inline, not allocated on the heap. For instance, a `Pair<long, double>` that isn't a pointer, but is instead the exactly the size of a long plus a double, and is the same as writing `long first; double second;` inline.

sporkland 8y ago

Dumb question. Why do reified generics make interop challenging? Or is it reified generics plus value types that don't inherit system.Object? Couldn't the language implementations basically pass around ICollection<Object> in .NET somewhat similar to how they do in Java?

munchbunny 8y ago
The problem is that your GenericClass<T1> and GenericClass<T2> are really more like GenericClass_T1 and GenericClass_T2 with their own distinct type definitions and interfaces. From the perspective of a different runtime/language trying to interop with these types, you have to somehow understand and work with this mapping game. It's much easier from inside the .NET runtime than outside. The general solution is, like you suggested, to avoid using reified generics in the module interface where the interop happens.
- bunderbunder 8y ago
  The solution I remember from the last time I dealt with Python on .NET (which was admittedly a long time ago) was the opposite - you did use the reified generics, and there were facilities to create an instance of GenericClass<TWhatever> from within Python. There's a whole dynamic language runtime that is purpose-built for smoothing over a lot of that stuff. What wouldn't work would be to, e.g., create a Python-native list and try to pass it into a function that expects a .NET IList<T>. Which doesn't feel that odd to me - they may have the same name, but otherwise they're very different types that have very different interfaces. That said, the Iron languages never took off. My personal story there is that all the new dynamic features that C# got with the release of the DLR pretty much killed my desire to interact with C# from a dynamic language. The release that gave me Python on .NET also turned C# itself into an acceptable enough Python for my needs.
pron 8y ago
> Why do reified generics make interop challenging? Suppose you have types A and B, such that A <: B. What is, then, the relationship between List<A> and List<B>? This question is called variance, and different languages have very different answers to this, but once generics are reified, the chosen variance strategy is baked into the runtime. > Couldn't the language implementations basically pass around ICollection<Object> in .NET somewhat similar to how they do in Java? They could, but then this adds significant runtime overhead at the interop layer. For example, a popular standard API may take a parameter of type List<int>. How do you then call it from, say, JavaScript, without an O(n) operation (and without changing JS)?

datavirtue 8y ago

The user is what matters. As a language user I want reified generics. Don't care what the implementers want.