4 ms·

It seems like the JVM has been more successful than most platforms at supporting other guest languages. Java is still dominant, but Kotlin's pretty popular (as

It seems like the JVM has been more successful than most platforms at supporting other guest languages. Java is still dominant, but Kotlin's pretty popular (as other comments have mentioned) and Scala has a nontrivial amount of usage. I think JRuby's also used some, but I'm not sure.

pjmlp 3y ago
Kotlin is popular on Android, because Google says jump and everyone jumps. All the other alternative languages had better times behind themselves. Groovy survives thanks Jenkins and Gradle.
WorldMaker 3y ago
Arguably a perspective here is not that the JVM is more successful but that simply that Java as a language is less successful/more deficient language than C# and leaves more evolutionary niches available for other languages to coexist in its ecosystem, whereas C# checks more boxes generally. One reading of the history of Kotlin is that is almost directly the reason for Kotlin's existence in the first place because Java itself fell so far behind C# state of the art. The DLR made it much easier for dynamic languages on .NET to interact and share infrastructure on top of the CLR, but it also gave C# directly just enough dynamic language powers that filled most people's use cases for that niche. Even in the current race between C# and F#, unless you are using features such as Units of Measure or Type Providers, there is often a sense of "you don't need to use F# because that feature will be eventually in C# anyway" and "F# is just a proving ground for C# ideas". The F# community continues to try to find marketing messages that aren't that and better highlight some of the niches that F# can fill that C# won't. The most recent attempts have been trying to position F# as a "data sciences" language useful for Notebook-driven development in direct comparison/competition to Python/R/Julia. C# actually is finally useful in Notebooks now and has some alright REPL support, but F# likely will always better fit that niche. It will be interesting to see if that marketing approach helps.
Someone 3y ago
> It seems like the JVM has been more successful than most platforms at supporting other guest languages I think that’s more because of the amount of good Java binaries than because the JVM is good at supporting alternative languages. Scala had to make a few design choices they would never have made if they didn’t want to target the JVM and be compatible with existing Java binaries. Examples: - having Option[T], but still having null, too. - value types aren’t supported in the JVM (yet), so they’ve had to implement them using classes. - scala’s reflection would have been easier to understand if they could have tweaked the JVM to implement it (scala had to work hard to map its type system to that of the JVM) - scala has its own integer classes that are subtly different from both Java’s value types and it’s integer classes. Kotlin mostly is Java with a different syntax. Like scala, it must be doing some magic to support its value classes. Also, as another post in this thread said, some languages my need a garbage collector that behaves different from the JVM one. If so, you either adapt, or give up running on the JVM.
- kaba0 3y ago
  Scala 3 has an option to exempt null from ordinary types, marking nullable types as T | None, so this is not related to the JVM, this can be completely decidable at compile type. The reflection claim is also questionable, as Scala used to be available for the CLR as well, but that version was abandoned, while the JVM is striving. In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance.
  - Someone 3y ago
    > Scala 3 has an option to exempt null from ordinary types, marking nullable types as T | None, so this is not related to the JVM I don’t know scala 3 well, but if it can make nonnullable types (that’s what “exempt null from ordinary types” means, isn’t it?), that’s not something the JVM knows about (although that may be changing with the addition of value types to the JVM) Even if that’s incorrect, there are plenty of other examples of types that map badly to the JVM, such as Either[String,String] and AnyVal (a scala class with subclasses such as Int) Another example are value classes, which are values until they aren’t. https://docs.scala-lang.org/overviews/core/value-classes.html https://docs.scala-lang.org/overviews/core/value-classes.htm...: “Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation” And yes, scala3 has opaque types, but in the JVM, those must revert to their underlying type (if they don’t, the performance gains are lost), and scala3 also still has value classes. > this can be completely decidable at compile time. It can’t the moment you load a jar and call a method in it, and I think about every scala program does that. > The reflection claim is also questionable The JVM has strict single inheritance. Scala supports a form of multiple inheritance through traits. There’s no trivial way to map that to the JVM. > In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance. I don’t understand that. It surely doesn’t always help. Scala reflection doesn’t want erasure, so they’ve had to work around that.
    - kaba0 3y ago
      > I don’t know scala 3 well, but if it can make nonnullable types (that’s what “exempt null from ordinary types” means, isn’t it?), that’s not something the JVM knows about (although that may be changing with the addition of value types to the JVM) Haskell or Rust compiles to machine code, which can have invalid/null pointers as well they don’t know about. Nullness is a so-called trivial property, the compiler can prove the absence of NPEs in code output by it, so you only have to check at the boundaries (e.g. every java method will return a nullable type) I don’t know why would these map badly to java types. Scala unifies primitives with their boxed versions and tries to smartly optimize between them, so it doesn’t have the kind of distinction as Java. Value classes require runtime support so the only thing Scala can do is to alias a primitive as another class, but optimize it away. Of course this is a leaky abstraction, but this is a fact of life on managed runtimes. Re multiple inheritance: doesn’t map natively, but this also doesn’t need native support. At worst, scala can always just go the Groovy way and intercept any call to/from every such object of theirs and then they can literally do any form of call indirection. Re reflection: as far as I know Scala doesn’t really require frequent use of reflection, as it can circumvent it at most times through metaprogramming/more expressive language features. Also, type erasure is the norm — most runtimes don’t store type infos.

pjmlp 3y ago

Kotlin is popular on Android, because Google says jump and everyone jumps. All the other alternative languages had better times behind themselves. Groovy survives thanks Jenkins and Gradle.

WorldMaker 3y ago

Arguably a perspective here is not that the JVM is more successful but that simply that Java as a language is less successful/more deficient language than C# and leaves more evolutionary niches available for other languages to coexist in its ecosystem, whereas C# checks more boxes generally. One reading of the history of Kotlin is that is almost directly the reason for Kotlin's existence in the first place because Java itself fell so far behind C# state of the art. The DLR made it much easier for dynamic languages on .NET to interact and share infrastructure on top of the CLR, but it also gave C# directly just enough dynamic language powers that filled most people's use cases for that niche. Even in the current race between C# and F#, unless you are using features such as Units of Measure or Type Providers, there is often a sense of "you don't need to use F# because that feature will be eventually in C# anyway" and "F# is just a proving ground for C# ideas". The F# community continues to try to find marketing messages that aren't that and better highlight some of the niches that F# can fill that C# won't. The most recent attempts have been trying to position F# as a "data sciences" language useful for Notebook-driven development in direct comparison/competition to Python/R/Julia. C# actually is finally useful in Notebooks now and has some alright REPL support, but F# likely will always better fit that niche. It will be interesting to see if that marketing approach helps.

Someone 3y ago

> It seems like the JVM has been more successful than most platforms at supporting other guest languages I think that’s more because of the amount of good Java binaries than because the JVM is good at supporting alternative languages. Scala had to make a few design choices they would never have made if they didn’t want to target the JVM and be compatible with existing Java binaries. Examples: - having Option[T], but still having null, too. - value types aren’t supported in the JVM (yet), so they’ve had to implement them using classes. - scala’s reflection would have been easier to understand if they could have tweaked the JVM to implement it (scala had to work hard to map its type system to that of the JVM) - scala has its own integer classes that are subtly different from both Java’s value types and it’s integer classes. Kotlin mostly is Java with a different syntax. Like scala, it must be doing some magic to support its value classes. Also, as another post in this thread said, some languages my need a garbage collector that behaves different from the JVM one. If so, you either adapt, or give up running on the JVM.

kaba0 3y ago
Scala 3 has an option to exempt null from ordinary types, marking nullable types as T | None, so this is not related to the JVM, this can be completely decidable at compile type. The reflection claim is also questionable, as Scala used to be available for the CLR as well, but that version was abandoned, while the JVM is striving. In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance.
- Someone 3y ago
  > Scala 3 has an option to exempt null from ordinary types, marking nullable types as T | None, so this is not related to the JVM I don’t know scala 3 well, but if it can make nonnullable types (that’s what “exempt null from ordinary types” means, isn’t it?), that’s not something the JVM knows about (although that may be changing with the addition of value types to the JVM) Even if that’s incorrect, there are plenty of other examples of types that map badly to the JVM, such as Either[String,String] and AnyVal (a scala class with subclasses such as Int) Another example are value classes, which are values until they aren’t. https://docs.scala-lang.org/overviews/core/value-classes.html https://docs.scala-lang.org/overviews/core/value-classes.htm...: “Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation” And yes, scala3 has opaque types, but in the JVM, those must revert to their underlying type (if they don’t, the performance gains are lost), and scala3 also still has value classes. > this can be completely decidable at compile time. It can’t the moment you load a jar and call a method in it, and I think about every scala program does that. > The reflection claim is also questionable The JVM has strict single inheritance. Scala supports a form of multiple inheritance through traits. There’s no trivial way to map that to the JVM. > In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance. I don’t understand that. It surely doesn’t always help. Scala reflection doesn’t want erasure, so they’ve had to work around that.
  - kaba0 3y ago
    > I don’t know scala 3 well, but if it can make nonnullable types (that’s what “exempt null from ordinary types” means, isn’t it?), that’s not something the JVM knows about (although that may be changing with the addition of value types to the JVM) Haskell or Rust compiles to machine code, which can have invalid/null pointers as well they don’t know about. Nullness is a so-called trivial property, the compiler can prove the absence of NPEs in code output by it, so you only have to check at the boundaries (e.g. every java method will return a nullable type) I don’t know why would these map badly to java types. Scala unifies primitives with their boxed versions and tries to smartly optimize between them, so it doesn’t have the kind of distinction as Java. Value classes require runtime support so the only thing Scala can do is to alias a primitive as another class, but optimize it away. Of course this is a leaky abstraction, but this is a fact of life on managed runtimes. Re multiple inheritance: doesn’t map natively, but this also doesn’t need native support. At worst, scala can always just go the Groovy way and intercept any call to/from every such object of theirs and then they can literally do any form of call indirection. Re reflection: as far as I know Scala doesn’t really require frequent use of reflection, as it can circumvent it at most times through metaprogramming/more expressive language features. Also, type erasure is the norm — most runtimes don’t store type infos.