4 ms·

If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the

If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the newer build configurations; even F# is playing catch-up and they're part of the official toolchain.

pjmlp 3y ago
That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.
- HappMacDonald 3y ago
  It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
- no_wizard 3y ago
  I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
  - pjmlp 3y ago
    Nah, only on ART. No JVM will ever be rewriten in Kotlin for it to matter outside Android.
    - RussianCow 3y ago
      Why would the JVM need to be rewritten in Kotlin for it to "matter"?
    - wiseowise 3y ago
      Kotlin is an official language of Spring, Vert.x, Micronaut, Gradle and IntelliJ platform. What are you talking about?
  - alexvitkov 3y ago
    Kotlin is Java with minor syntax changes - it brings nothing new to the table and you write it the exact same way as you would Java. It's an easy sell for shops that want the feeling they're making forward progress in the field of computing but who don't actually want to change anything.
    - wiseowise 3y ago
      That’s factually wrong. Null-safety alone changes completely how you write Kotlin, add to that coroutines, extension functions and dozen other quality of life improvements and you get completely different style.
- DylanSp 3y ago
  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.

pjmlp 3y ago

That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.

HappMacDonald 3y ago
It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
no_wizard 3y ago
I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
- pjmlp 3y ago
  Nah, only on ART. No JVM will ever be rewriten in Kotlin for it to matter outside Android.
  - RussianCow 3y ago
    Why would the JVM need to be rewritten in Kotlin for it to "matter"?
  - wiseowise 3y ago
    Kotlin is an official language of Spring, Vert.x, Micronaut, Gradle and IntelliJ platform. What are you talking about?
- alexvitkov 3y ago
  Kotlin is Java with minor syntax changes - it brings nothing new to the table and you write it the exact same way as you would Java. It's an easy sell for shops that want the feeling they're making forward progress in the field of computing but who don't actually want to change anything.
  - wiseowise 3y ago
    That’s factually wrong. Null-safety alone changes completely how you write Kotlin, add to that coroutines, extension functions and dozen other quality of life improvements and you get completely different style.
DylanSp 3y ago
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.