6 ms·

What ended up happening to the .NET target?

saryant 13y ago
It hasn't been maintained so it's getting axed in 2.11.
octo_t 13y ago
the CLRs type system is in the annoying place of being both too powerful and underpowered to support scala's type system. If it was weaker (á la JVM) it would be fine, if it was more powerful it could represent stuff at runtime. I'm trying to find a link to the paper which says there is not an efficient one-to-one mapping from Scala to CLR
- noblethrasher 13y ago
  Hope you find the link; I'd like to read that paper.
densh 13y ago
I've seen a few people reporting running Scala on .NET successfully with the help of IKVM [1] [1] http://www.ikvm.net/ http://www.ikvm.net/
- stusmall 13y ago
  I've seen this project listed before but have never used it. Can anyone with a decent amount of experience with it speak to the quality of it?
platz 13y ago
I heard the internals of the Scala compiler are really ugly and there isn't a true spec for why it does some of the things it does. So it might be hard to just make it match what the existing compiler does, because it's defined by it's implementation and it's hard to understand?
- frowaway001 13y ago
  Not really. Yes, some parts are a bit involved, but it's better thanmost compilers out there. People are complaining at a pretty high level here. The death of the .NET port can directly be attributed to Microsoft's marketing of the platform. If they manage to make people question whether .NET will still be alive in 10 years, it's no surprise that people start dropping support for it.
  - platz 13y ago
    My sample size is small, but the sentiment mainly comes from this: "Pacific Northwest Scala 2013 We're Doing It All Wrong by Paul Phillips - YouTube" [1] [1] https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg
    - frowaway001 13y ago
      While I usually agree with most things Paul Phillips says, that talk was mostly an exception. There is nothing which can't be fixed by focused work on all the bits and pieces which need work, and that's exactly what the scalac compiler developers are doing most of the time. So many improvements are coming in every week that I can hardly stand using an older compiler version, because I always know that so much stuff has already substantially improved. Despite what some people say, life in Scala-land is pretty damn good.
laureny 13y ago
It died, because .net supports reified types, which make interoperability pretty much impossible. Contrary to popular opinion, erasure is a superior solution to reification for many reasons, and this is one of them.
- tomp 13y ago
  Can you be more specific? I know that reification can bloat runtime memory requirements, but I'd like to know about other disadvantages.
  - noblethrasher 13y ago
    This might help: http://beust.com/weblog/2011/07/29/erasure-vs-reification/ http://beust.com/weblog/2011/07/29/erasure-vs-reification/
    - tomp 13y ago
      Not really... this only mentions that reified generics would be incompatible with current Java collections, which is obviously a problem that Java has, not that reified generics have (C# does great!).
      - bad_user 13y ago
        C# was designed for the CLR and the CLR was designed for C#. F# on the other hand has 2 generics systems in the same language, one inherited from C# and one for ML-style Hindley–Milner based on type-erasure and they don't interact well. Java's generics can't be built on top of the CLR's reified generics, but this goes for other languages as well - Haskell, ML, Scala, you name it. Basically, reified generics work well in case you design the language in combination with the VM, otherwise it becomes a huge PITA. FYI, the CLR's reified generics is one reason for why the JVM is a better target for other languages. For dynamic languages, they are a problem because the bytecode generator has to work around them. For static languages, such as Scala or anything in the ML family, it's a problem because either (a) they are designed for co/contra-variance or (b) they don't support higher-kinded types or (c) they don't support rank-2 types or (d) in case you do need co/contra-variance rules, for some reason Microsoft chose to restrict the declarations only to generic interfaces and delegates, so you can't design a List<+T> class for example (to be honest, I'm not sure if this last one is a limitation of the language or the CLR). Also, having reified generics is less important than you think. Scala for example can do specialization for primitive types and because the type-system is much stronger, coupled with an awesome collections library and pattern matching, the flow of the types is much better. For example, I can't remember any instance in which I felt the need to do a (obj isInstanceOf List<int>) check, immutable collections can be covariant without issues and for everything else there are type-classes, something which C# sorely lacks. IMHO, in spite of people's opinion on the matter, Java's type-erased generics is one of its best features.

It hasn't been maintained so it's getting axed in 2.11.

the CLRs type system is in the annoying place of being both too powerful and underpowered to support scala's type system. If it was weaker (á la JVM) it would be fine, if it was more powerful it could represent stuff at runtime. I'm trying to find a link to the paper which says there is not an efficient one-to-one mapping from Scala to CLR

noblethrasher 13y ago
Hope you find the link; I'd like to read that paper.

densh 13y ago

I've seen a few people reporting running Scala on .NET successfully with the help of IKVM [1] [1] http://www.ikvm.net/ http://www.ikvm.net/

stusmall 13y ago
I've seen this project listed before but have never used it. Can anyone with a decent amount of experience with it speak to the quality of it?

platz 13y ago

I heard the internals of the Scala compiler are really ugly and there isn't a true spec for why it does some of the things it does. So it might be hard to just make it match what the existing compiler does, because it's defined by it's implementation and it's hard to understand?

frowaway001 13y ago
Not really. Yes, some parts are a bit involved, but it's better thanmost compilers out there. People are complaining at a pretty high level here. The death of the .NET port can directly be attributed to Microsoft's marketing of the platform. If they manage to make people question whether .NET will still be alive in 10 years, it's no surprise that people start dropping support for it.
- platz 13y ago
  My sample size is small, but the sentiment mainly comes from this: "Pacific Northwest Scala 2013 We're Doing It All Wrong by Paul Phillips - YouTube" [1] [1] https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg
  - frowaway001 13y ago
    While I usually agree with most things Paul Phillips says, that talk was mostly an exception. There is nothing which can't be fixed by focused work on all the bits and pieces which need work, and that's exactly what the scalac compiler developers are doing most of the time. So many improvements are coming in every week that I can hardly stand using an older compiler version, because I always know that so much stuff has already substantially improved. Despite what some people say, life in Scala-land is pretty damn good.

laureny 13y ago

It died, because .net supports reified types, which make interoperability pretty much impossible. Contrary to popular opinion, erasure is a superior solution to reification for many reasons, and this is one of them.

tomp 13y ago
Can you be more specific? I know that reification can bloat runtime memory requirements, but I'd like to know about other disadvantages.
- noblethrasher 13y ago
  This might help: http://beust.com/weblog/2011/07/29/erasure-vs-reification/ http://beust.com/weblog/2011/07/29/erasure-vs-reification/
  - tomp 13y ago
    Not really... this only mentions that reified generics would be incompatible with current Java collections, which is obviously a problem that Java has, not that reified generics have (C# does great!).
    - bad_user 13y ago
      C# was designed for the CLR and the CLR was designed for C#. F# on the other hand has 2 generics systems in the same language, one inherited from C# and one for ML-style Hindley–Milner based on type-erasure and they don't interact well. Java's generics can't be built on top of the CLR's reified generics, but this goes for other languages as well - Haskell, ML, Scala, you name it. Basically, reified generics work well in case you design the language in combination with the VM, otherwise it becomes a huge PITA. FYI, the CLR's reified generics is one reason for why the JVM is a better target for other languages. For dynamic languages, they are a problem because the bytecode generator has to work around them. For static languages, such as Scala or anything in the ML family, it's a problem because either (a) they are designed for co/contra-variance or (b) they don't support higher-kinded types or (c) they don't support rank-2 types or (d) in case you do need co/contra-variance rules, for some reason Microsoft chose to restrict the declarations only to generic interfaces and delegates, so you can't design a List<+T> class for example (to be honest, I'm not sure if this last one is a limitation of the language or the CLR). Also, having reified generics is less important than you think. Scala for example can do specialization for primitive types and because the type-system is much stronger, coupled with an awesome collections library and pattern matching, the flow of the types is much better. For example, I can't remember any instance in which I felt the need to do a (obj isInstanceOf List<int>) check, immutable collections can be covariant without issues and for everything else there are type-classes, something which C# sorely lacks. IMHO, in spite of people's opinion on the matter, Java's type-erased generics is one of its best features.