4 ms·

Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). E

Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages. For example, Imagine you have an api like `void do(List<Foo> foos)`. In the erasure environment of the JVM that looks like `void do(List foos)`. From python it's pretty easy to call with a `foos = [Foo()]`. But not so much if your python implementation needs to figure out how and if it can coarse it's `List` type into a `List<Foo>` type.

kuhsaft 4mo ago
I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java. Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users. Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.
- cogman10 4mo ago
  You CAN do it, but it's much more difficult. And as far as I'm aware, both kotlin and Scala don't really suffer due to type erasure.
  - kuhsaft 4mo ago
    I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages. That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java. And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.
- pregnenolone 4mo ago
  > Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM. The creator of Scala disagrees: https://youtu.be/Xn_YpUtXWT4?t=850 https://youtu.be/Xn_YpUtXWT4?t=850
  - kuhsaft 4mo ago
    Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime. The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features. TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features. I do think the C#/CLR struct implementation is better though.
WorldMaker 4mo ago
IronPython did just fine with reified generics.
- kuhsaft 4mo ago
  There's also https://github.com/ikvmnet/ikvm https://github.com/ikvmnet/ikvm that converts Java bytecode to CIL; essentially Java on CLR.
- pjmlp 4mo ago
  Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.
  - kuhsaft 4mo ago
    Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast. I suppose DLR would be comparable to GraalVM/Truffle. The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management. I think an interesting project would be to implement a CIL interpreter on GraalVM.
    - pjmlp 4mo ago
      DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used. GraalVM already handles LLVM bitcode, much cooler than plain MSIL. And here there is another example where Java ecosystem ends up being better. MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.
      - cogman10 4mo ago

kuhsaft 4mo ago

I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java. Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users. Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.

cogman10 4mo ago
You CAN do it, but it's much more difficult. And as far as I'm aware, both kotlin and Scala don't really suffer due to type erasure.
- kuhsaft 4mo ago
  I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages. That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java. And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.
pregnenolone 4mo ago
> Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM. The creator of Scala disagrees: https://youtu.be/Xn_YpUtXWT4?t=850 https://youtu.be/Xn_YpUtXWT4?t=850
- kuhsaft 4mo ago
  Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime. The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features. TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features. I do think the C#/CLR struct implementation is better though.

WorldMaker 4mo ago

IronPython did just fine with reified generics.

kuhsaft 4mo ago
There's also https://github.com/ikvmnet/ikvm https://github.com/ikvmnet/ikvm that converts Java bytecode to CIL; essentially Java on CLR.
pjmlp 4mo ago
Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.
- kuhsaft 4mo ago
  Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast. I suppose DLR would be comparable to GraalVM/Truffle. The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management. I think an interesting project would be to implement a CIL interpreter on GraalVM.
  - pjmlp 4mo ago
    DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used. GraalVM already handles LLVM bitcode, much cooler than plain MSIL. And here there is another example where Java ecosystem ends up being better. MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.
    - cogman10 4mo ago