3 ms·

My understanding is that the problem was, more specifically, that they couldn't easily get Scala's types mated to .NET, and that was in turn an implication of t

My understanding is that the problem was, more specifically, that they couldn't easily get Scala's types mated to .NET, and that was in turn an implication of the decision to use IKVM to run the Java binaries for Scala's standard libraries on the CLR. Which I could see being a problem, because then you need to figure out how to smoothly marshal data back and forth between (type erased) Scala collections and .NET functions, which typically expect reified types these days. If they had gone with producing a .NET native version of Scala's standard libraries, they might have had easier success. But it also would have been a Pyrrhic victory, because you'd have lost the ability to run any existing Scala code, which would have scads of dependencies on other bits of the JDK as well, on Scala for .NET. At which point, what's the point? I expect that porting F# to the JVM would encounter similar problems. And I expect that which platform you want to blame them on depends on which one is your home platform. IMO the real story here is that the two big managed platforms are effectively walled gardens, by virtue of having VMs that implement such very high-level bytecode. Both of them effectively demand that all languages running on them can interact with, in effect, a thoroughly object-oriented ABI. There being approximately as may flavors of OOP as there are OO languages, that creates a situation where, if your language isn't set up to play nice with that platform's particular brand of OOP, you're going to have a bad time.

dtech 8y ago
> But it also would have been a Pyrrhic victory, because you'd have lost the ability to run any existing Scala code, which would have scads of dependencies on other bits of the JDK as well, on Scala for .NET. At which point, what's the point? Ask the parade of JVM languages porting themselves to native and JS runtimes.
- bunderbunder 8y ago
  Those are both very different use cases.
  - tutanchamun 8y ago
    Why are they very different? They port the language over to another platform and need to interop with it. For example scala.js can call js libraries through facades (similar to typescript typing files) but can also be called from javascript. Scala.native can call c libraries (I have no idea about the other way around).
    - bunderbunder 8y ago
      Targeting native because it's fundamentally a less thorny issue. To an approximation, all you do is take the JIT compilation pipeline and use it to do an AOT compilation instead. Targeting JavaScript because people expect different things out of it. The goal there is to transpile some portion of your code to run on the browser. There's not the same expectation that you'll be able to truck Spring or Akka along with you. The expectation is that the transpiled code is mostly only going to interact with the DOM and other JavaScript libraries, plus maybe whatever subset of your business objects you feel the need to have on both the client and server side. By contrast, the only real use case I can see for porting Scala to .NET is so that you can bring a bunch of pre-existing Scala libraries with you and then interface them with some pre-existing .NET codebase. If you're not looking for that, you'd probably be willing to satisfy yourself with either F# or the JVM.
seanmcdirmid 8y ago
I agree with most of what you said, but porting an erased language to the JVM is not very hard. Porting a reified generic language to the JVM would be challenging because genetics would have to be reified perhaps inefficiently, while clean interop would be impossible. The JVM was never meant for other languages, that just happened, and most of the non-Java languages were designed to live nicely in the JVM world. The CLR is a bit more ambiguous, but I think it’s safe to say at this point that it is even less suited to other languages not designed specifically for it.
- bunderbunder 8y ago
  I think it's safe to say that was the case before .NET 4 introduced the dynamic language runtime. Afterwards, I'm not so sure - it seems like the story there was that the .NET team put a whole lot of work into building support for IronRuby and IronPython, but the languages themselves failed to take off for other reasons. Lack of community need/interest, for one. To me, the more interesting test is, could you do a useful port of a language like C or Pascal or ML to the JVM or the CLR, while having it remain the same language. My instinct is that it's equally unworkable for both platforms. Requiring erasure vs reification is a small difference compared to the major demand that both platforms make, which is that any languages targeting them need to be at least partially object-oriented.
  - seanmcdirmid 8y ago
    The DLR was only going to ever work out for dynamic languages, and even then I think it was pretty limited to class-based ones like Python and Ruby. Unfortunately, the DLR seems to be pretty much deprecated at this point. Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP).
    - benaadams 8y ago
      > Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP). That's more to do with UWP being a AOT platform than it being deprecated; it should still work fine with .NET Core?
eeperson 8y ago
> But it also would have been a Pyrrhic victory, because you'd have lost the ability to run any existing Scala code, which would have scads of dependencies on other bits of the JDK as well, on Scala for .NET. At which point, what's the point? Wouldn't it be in the same boat as scala-js? There are quite a few libraries that support scala-jvm and scala-js.

dtech 8y ago

> But it also would have been a Pyrrhic victory, because you'd have lost the ability to run any existing Scala code, which would have scads of dependencies on other bits of the JDK as well, on Scala for .NET. At which point, what's the point? Ask the parade of JVM languages porting themselves to native and JS runtimes.

bunderbunder 8y ago
Those are both very different use cases.
- tutanchamun 8y ago
  Why are they very different? They port the language over to another platform and need to interop with it. For example scala.js can call js libraries through facades (similar to typescript typing files) but can also be called from javascript. Scala.native can call c libraries (I have no idea about the other way around).
  - bunderbunder 8y ago
    Targeting native because it's fundamentally a less thorny issue. To an approximation, all you do is take the JIT compilation pipeline and use it to do an AOT compilation instead. Targeting JavaScript because people expect different things out of it. The goal there is to transpile some portion of your code to run on the browser. There's not the same expectation that you'll be able to truck Spring or Akka along with you. The expectation is that the transpiled code is mostly only going to interact with the DOM and other JavaScript libraries, plus maybe whatever subset of your business objects you feel the need to have on both the client and server side. By contrast, the only real use case I can see for porting Scala to .NET is so that you can bring a bunch of pre-existing Scala libraries with you and then interface them with some pre-existing .NET codebase. If you're not looking for that, you'd probably be willing to satisfy yourself with either F# or the JVM.

seanmcdirmid 8y ago

I agree with most of what you said, but porting an erased language to the JVM is not very hard. Porting a reified generic language to the JVM would be challenging because genetics would have to be reified perhaps inefficiently, while clean interop would be impossible. The JVM was never meant for other languages, that just happened, and most of the non-Java languages were designed to live nicely in the JVM world. The CLR is a bit more ambiguous, but I think it’s safe to say at this point that it is even less suited to other languages not designed specifically for it.

bunderbunder 8y ago
I think it's safe to say that was the case before .NET 4 introduced the dynamic language runtime. Afterwards, I'm not so sure - it seems like the story there was that the .NET team put a whole lot of work into building support for IronRuby and IronPython, but the languages themselves failed to take off for other reasons. Lack of community need/interest, for one. To me, the more interesting test is, could you do a useful port of a language like C or Pascal or ML to the JVM or the CLR, while having it remain the same language. My instinct is that it's equally unworkable for both platforms. Requiring erasure vs reification is a small difference compared to the major demand that both platforms make, which is that any languages targeting them need to be at least partially object-oriented.
- seanmcdirmid 8y ago
  The DLR was only going to ever work out for dynamic languages, and even then I think it was pretty limited to class-based ones like Python and Ruby. Unfortunately, the DLR seems to be pretty much deprecated at this point. Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP).
  - benaadams 8y ago
    > Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP). That's more to do with UWP being a AOT platform than it being deprecated; it should still work fine with .NET Core?

eeperson 8y ago

> But it also would have been a Pyrrhic victory, because you'd have lost the ability to run any existing Scala code, which would have scads of dependencies on other bits of the JDK as well, on Scala for .NET. At which point, what's the point? Wouldn't it be in the same boat as scala-js? There are quite a few libraries that support scala-jvm and scala-js.