4 ms·

JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific p

JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific problem domains I'd say CIL is probably better than JVM. Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)

lmm 13y ago
Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)
- moonchrome 13y ago
  It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages. Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
  - sixbrx 13y ago
    Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.
  - bad_user 13y ago
    > It's not like Scala has generics interop with Java Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode. > you can't use advanced Scala generics from Java I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it? > I'm sure they could have erased the extra stuff on CIL Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics. As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all). > Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types. That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...
- TheAnimus 13y ago
  Do you have any links on this? I had a quick duckduck but sadly nothing much came up. My understanding of 'type erasure' is that it is a compiler step, that un-does all the generic information. This means that you could just ignore CLR generics, interop not withstanding, to get it to run. Why would this prevent anything been ported?
bad_user 13y ago
> JVM doesn't even have value types or generics making it practically unusable in some scenarios Like what? The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything. The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic. As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities. > Not to mention CIL was designed to be a Common Intermediate Language from start That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.
- Edmond 13y ago
  >As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing). Speaking of those, if anyone wants to try those languages on the jvm for web app development check out HiveMind (crudzilla.com)...I am the developer, it is the easiest platform so far for using JSR-223 to build web apps. here's a quick gif demo: http://bit.ly/1k7nG2n http://bit.ly/1k7nG2n

lmm 13y ago

Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)

moonchrome 13y ago
It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages. Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
- sixbrx 13y ago
  Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.
- bad_user 13y ago
  > It's not like Scala has generics interop with Java Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode. > you can't use advanced Scala generics from Java I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it? > I'm sure they could have erased the extra stuff on CIL Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics. As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all). > Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types. That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...
TheAnimus 13y ago
Do you have any links on this? I had a quick duckduck but sadly nothing much came up. My understanding of 'type erasure' is that it is a compiler step, that un-does all the generic information. This means that you could just ignore CLR generics, interop not withstanding, to get it to run. Why would this prevent anything been ported?

bad_user 13y ago

> JVM doesn't even have value types or generics making it practically unusable in some scenarios Like what? The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything. The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic. As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities. > Not to mention CIL was designed to be a Common Intermediate Language from start That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.

Edmond 13y ago
>As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing). Speaking of those, if anyone wants to try those languages on the jvm for web app development check out HiveMind (crudzilla.com)...I am the developer, it is the easiest platform so far for using JSR-223 to build web apps. here's a quick gif demo: http://bit.ly/1k7nG2n http://bit.ly/1k7nG2n