8 ms·

Scala comes to .Net

95 points by markokocic 15y ago

wccrawford 15y ago
And it appears I'm official negligent about learning Scala. I know it's been around for years, but I just really learned about it recently and now it seems to be going crazy. With the ability to use .NET or the JVM... I mean, wow.
JohnLBevan 15y ago
They should give it a more dot netty name, by picking a letter (maybe F, as it's a functional language) and putting a sharp on the end.
- cipherpunk 15y ago
  Yes. Pretty sure that hasn't been done before! :D
- agscala 15y ago
  S# :)
danieldk 15y ago
Since most serious Scala programs will use Java classes or class libraries, I still have to see how portable most Scala code will be between JVM and .NET/CLR, besides the lack of ABI compatibility. It will add complexity to a language that is already fairly complex. Some commenters have already suggested that Scala has the C++ syndrome, but at least C++ is easily wrapped in C, making binding to anything else fairly easy. I wonder if it would not be better to stick to the JVM, and tell people that that's the platform. You cannot be everything to everyone without collapsing under the weight.
- markokocic 15y ago
  Well, Scala is not the simplest language, but I'm not sure why having separate .Net backend will make the language more complex. After all, .Net and JVM are pretty similar at its core so that difference between the two shouldn't affect Scala the language, only Scala the compiler. As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
  - danieldk 15y ago
    Right, you are paraphrasing my worry: there will be .Net and Java flavors Scala. Sure, the syntax will be portable, but programs do not only consist of syntax. C# in the .Net 1.0 era was very similar to Java. However, most of the domain-specific knowledge is not in the language, but in the associated class library and runtime. Usage patterns evolve with them. So, under the assumption that Scala.Net will get traction, in three years, people will be hiring Scala.Net and Scala(JVM) programmers. Educational programs will teaching two different flavors. Books will describe two different flavors. How does this help Scala or the Scala programmer? (Then there are more questions, such as: what does Scala.Net offer over C# (which is incorporating functional constructs) and F#?)
    - jbrechtel 15y ago
      IIRC 'Programming in Scala' doesn't talk much about the JVM.
    - markokocic 15y ago
      While we both agree what would happen, I don't see that as a bad thing. With core language being the same, lots of the skill will be portable. We have the same situation right now with C/C++, where people are hiring Windows C++ programmers and Linux C++ programmers. It doesn't seem to hurt that much C++ as a language. And C++ has even smaller "standard library" than Scala.
      - danieldk 15y ago
        C++ has a smaller standard library, but has easier interoperability with other languages. I see your point, but I do think it hurts C++ and C++ programmers. Programming C++ in Windows or programming C++ in a gtkmm context are very different. Even the most basic things are not standardized (unicode string handling, etc.). Middle ground does exist (Qt), but it does replace most of the STL and has some very basic weaknesses, like vectors that are limited to 2^31 − 1 elements on common platforms. So, again, I am seriously interested in what fragmentation buys you when porting to a platform that already has 1 1/2 functional languages, supported by its developer?
- jcromartie 15y ago
  This is basically the same reason that ClojureCLR has no traction.
  - cema 15y ago
    One of the reasons. In general, I can see a low rate of acceptance of .NET among the crowd which has a high rate of interest in Clojure. I guess it is a case of avoiding Microsoft-dominated technologies by the open-source crowd.
    - code_duck 15y ago
      And the Microsoft crowd is sometimes reluctant to embrace non-Microsoft technologies.
      - cema 15y ago
        This is true, but I think the reasons are different. There has been a lot of usage knowledge created around the Microsoft platform(s), some supported by the community, but a lot still supported by the company. Moving in the open-source realm means losing a company's support, and I can see how those who are not used to it are uncomfortable with it.
        code_duck 15y ago
        I don't see how that's too different than if a dedicated open source user was to move to using MS products. Replace 'Microsoft' with OSS and 'company' with 'community', and the statement is still true.
    - jcromartie 15y ago
      As someone who uses both, I'll gladly be a supporting data point for this hypothesis.
      - barighona 15y ago
        http://onlinepctvlink.blogspot.com/2011/07/nrl-rugby-st-george-dragons-vs-sharks.html http://onlinepctvlink.blogspot.com/2011/07/nrl-rugby-st-geor...
gtani 15y ago
This uses IKVM heavily, and it sounds like other people have tried running scala classfiles through IKVM http://groups.google.com/group/scala-user/browse_frm/thread/22c59173038a587a# http://groups.google.com/group/scala-user/browse_frm/thread/... and a LLVM backend project is also brewing http://news.ycombinator.com/item?id=2625405 http://news.ycombinator.com/item?id=2625405
ludwigvan 15y ago
The danger with this is, how long will it be supported? Can the Scala team ensure that it will not be deprecated in the future? With JVM, one is confident of future. I remember Microsoft letting go of the IronRuby developers, for example, has IronRuby's development stagnated as well? (I'm aware that the work is done by the Scala team in this case, though)
Fice 15y ago
Pragmatism over principle again; today's hacker culture is crippled.
- rit 15y ago
  Getting Shit Done trumps all things. The reality as well is that the majority of the .Net platform (with the exception of the Standard Libraries, I believe) are open ECMA Standards (See among others, #335).
  - Fice 15y ago
    The reality is that .NET is a very probable patent trap for the FOSS community and Microsoft is trying hard to make us dependent on it. Unlike .NET, Java has a free implementation (OpenJDK) and any code derived from OpenJDK is granted Java patents. Apache is a different story as they are developing a Java implementation under permissive license, which means that Apache code could be used in non-free software (including .NET), that would make Java vulnerable to the "Embrace, Extend and Extinguish" strategy. That is what Apache is paid for by Microsoft. So my point is that supporting .NET is bad for the ideals of the free software community, yet it is good for pragmatic reasons as it could bring more users. And I have a strong impression that today pragmatism is favored over principle by the community, the decline of copyleft is also a sign of that.
    - macca321 15y ago
      So is it that you don't buy the Community Promise, or that you don't know about it? http://tirania.org/blog/archive/2009/Jul-06.html http://tirania.org/blog/archive/2009/Jul-06.html
      - Fice 15y ago
        FSF: Microsoft's Empty Promise (http://www.fsf.org/news/2009-07-mscp-mono http://www.fsf.org/news/2009-07-mscp-mono)
    - rit 15y ago
alexro 15y ago
How many companies that do both .Net and Java development and use Scala there are? Or how many will start developing in Scala if they're already proficient in .net? Definitely there will be some, but to base the compiler of such complexity around these few ... well, I just don't think it's worth the effort.
- smcj 15y ago
  Well, the Scala developers are currently moving their build system to Scala. This means they can fully bootstrap their language/compiler, library and build system from one source language. The .NET port has only added some minor changes to the compiler (which have actually uncovered a bug in the compiler implementation!) and most of the .NET backend works as a compiler plugin, just like the JVM backend or the LLVM backend.
- icey 15y ago
  I've always looked at Scala as a great language to go to if you don't want to be on the .Net stack. But if you're happy with the .Net ecosystem, the combination of C# and F# are very tough to beat. The tooling is great, and the languages are really well thought out. I don't really know what benefits there are to gain from using Scala on .Net other than the fact that it's cool that it could be done.
skrebbel 15y ago
To me, the obvious use case is not bringing the .Net platform to Scala developers, but bringing Scala to .Net developers. At my company, we do a large majority of our work in .Net languages, mostly C#. Being able to incrementally mix some Scala code into this for additional productivity, especially in the areas where Scala rocks (such as distributed / parallel processing, or in-language DSLs such as Scala's parsing library), sounds like a big win. Support for C# generics is a must for that, though; you need to be able to pass List<Banana>s around. Like other commenters said, the only danger is if the Scala guys would decide to stop supporting the CLR in the future again.
- danieldk 15y ago
  How does parallel processing in Scala "rock"? Can you point me to studies where Actors outperform, say OpenMP or Task Parallel Library? Does parallel processing on Scala compensate the overhead that Scala generally has over Java, C++, or in this case C#? I'd seriously like to know. I know that actors are good in some situations (distributed computing where you would normally use message passing), but statements such as the above can often be heard, but seem far to broad.
  - smcj 15y ago
    Why and how should actors outperform OpenMP or TPL? They serve completely different goals. Scala ships by default with sequential, lazy and parallel collections and actors. Akka (akka.io) provides a different implementation of actors (which will replace the one in the standard library in the future), as well as Agents, STM, Transactors, ... for all your concurrency needs. Akka actors can actually outperform Erlang actors in core areas. Spark (spark-project.org) provides a (Hadoop-like) framework for distributed collections. Work is being done to make Scala collections run on GPUs, too. I would argue that Scala's toolbox is pretty diverse and complete when dealing with parallel and/or concurrent problems. Without facts I wouldn't claim that Scala is slower than Java/C++/C#. Scala beats the shit out of Java in situations where Java has to work with boxed types instead of primitives like in ArrayList<Integer>, enables people to write fully generic algorithms supporting any number type without speed penalty. Scala is certainly nicer than C++ because it just works and has far less weird corners or surprises. It lets you write code faster and gives you more time to actually optimize those places where it matters. C# is pretty much a kitchen-sink language with many features bolted on in a non-othogonal way, unlike Scala. The unreliable VM doesn't help, although value types and the thing Mono did with SIMD is certainly nice.
PaulHoule 15y ago
C# programmers don't have the sense of desperation that Java programmers do. C# has non-broken generics, (contra/co)variance, closures, method pointers, expression trees, type inference, value types (can implement complex numbers that take up just 8 bytes!) and many other little features that show that the language designers have some respect for programmers. If anything, C# is the language that Java refugees are looking for, not Scala.
- smcj 15y ago
  Well, some might actually want co-variant return types and "real" variance instead of the interface/delegate as well as non-broken array variance, real type inference, higher-kinded types (to not loose the collection type like in LINQ) and many things more. That said, yes, C# looks a bit more familiar to Java developers although it is more or less a C++ descendant. Additionally, most Java developers want to stay on the JVM, because it guarantees high performance, stability and maturity and has a wealth of well-known third party libraries.
  - politician 15y ago
    If "most Java developers want to stay on the JVM, because X, Y, Z," then doesn't that support the OP reasoning that Scala on .NET is a solution looking for a problem?
- irahul 15y ago
  And C# programmers have F# to go to if they want to sample ML. I do not primarily program in C#, and I have done decent amount of Java. As far as languages are concerned, I find C# 4.0 a superior language to Java 6. I took a look at both Scala and F# - F# seemed simpler and more concise to me. One of my grudges is absence of a standard package manager for .net - Java has maven, ruby has gem, python has pip, C# has ?
  - dennyferra 15y ago
    C# now has one called NuGet. Edit* Just wanted to clarify it is not specifically for C# but the .NET platform in general.
hkarthik 15y ago
It's an interesting project, but in my 6+ years of Enterprise .NET development, I've yet to work in a single shop that released a production .NET application that wasn't written in C# or VB.NET. Even F# seems to be very rarely deployed. It's hard to get excited about any new CLR-based language development when clearly the broader .NET community and the customer base could care less.
- icey 15y ago
  They're out there - we embed IronPython in our C# application, and are looking into using F# for some of the financial reporting our application creates. It is rare, but there are definitely uses to having multiple languages available on the CLR (and DLR).
- ppog 15y ago
  This is probably a fair point about the "enterprise .NET" community, which is by nature very conservative and closely aligned to core Microsoft technologies where the guarantees of support are strongest and the developer pool the largest. However we as a smaller shop have used F# on a couple of projects within the last year -- to embed an expression engine within an analytics product, and for the parser/analyser in our Sass plugin for Visual Studio. But I know I'd have struggled to get that technology choice into the last enterprise environment I worked in. So the lack of uptake may be more to do with the culture of "enterprise .NET" shops, more than the "broader .NET community."
  - hkarthik 15y ago
    Well put. When I wrote "broader .NET community", I was mostly speaking to the vast majority of .NET developers, which are unfortunately stuck in typical Enterprise environments. There are definitely small shops out there doing interesting things and I love hearing about them!
sreque 15y ago
As someone who has recently learned C# and known Scala for a while, I am very impressed with what C# has to offer as a language. However, it is not nearly as well-designed as Scala. Microsoft has piled on feature after feature to the point where many C# are features either mostly deprecated and replaced by newer features or else do not mix well with new language features. Some examples include: -generic vs non-generic types. For instance, when using the Process class, you have to use StringDictionary. - Actions and delegates vs lambdas. This is made more painful by the fact that C# handles the void return type specially, so that there is no way to create a Func<void>. Also, it means that if you want to support higher order functions that support both a void and a generic return type you have to write two different functions. - ref and out parameters with lambdas. They just... don't mix! - out parameters vs 4.0 tuples. Really C# needed syntactic sugar for multiple return types long ago, but the idiomatic way to do this in C# is with a feature that simply does not play well with functional programming. There are other things that make Scala nicer as well. -In Scala every statement is also an expression and Scala has the bottom type, which again makes writing functional code much simpler. -Scala's collection's library is superior. It has functional collections and it's design enables overriding methods to have much more sensible static return types. -Scala's way of extending class functionality with implicits is more powerful and object-oriented than C#'s extension methods. In fact, Scala in general feels much more OO than C#. -Scala has a form of controlled multiple implementation inheritance (traits) that I really miss in C#. These are just the practical things I can think of on top of my head that I miss in C# versus Scala. On the other hand, I get the impression that C# was originally designed to be a more performant Java by hybridizing it with C++. It's richer value type system, the fact that class methods are non-virtual by deafult, and the ease by which one can drop into unsafe code mean that one can port a lot more performant C-style code to C# than on any JVM-originating language, which I think is C#'s greatest strength compared to Scala. Still, I think if people gave Scala a chance they would find it to be a very clean, productive, and well-designed language compared to C#. That alone may not be enough to convince people to switch to Scala in droves, but enough so that people who want to target both platforms will be willing to consider Scala as a solution rather than to use something like Mono.
- smcj 15y ago
  Couldn't say it any better, thanks!

95 points by markokocic 15y ago

And it appears I'm official negligent about learning Scala. I know it's been around for years, but I just really learned about it recently and now it seems to be going crazy. With the ability to use .NET or the JVM... I mean, wow.

JohnLBevan 15y ago

They should give it a more dot netty name, by picking a letter (maybe F, as it's a functional language) and putting a sharp on the end.

cipherpunk 15y ago
Yes. Pretty sure that hasn't been done before! :D
agscala 15y ago
S# :)

danieldk 15y ago

Since most serious Scala programs will use Java classes or class libraries, I still have to see how portable most Scala code will be between JVM and .NET/CLR, besides the lack of ABI compatibility. It will add complexity to a language that is already fairly complex. Some commenters have already suggested that Scala has the C++ syndrome, but at least C++ is easily wrapped in C, making binding to anything else fairly easy. I wonder if it would not be better to stick to the JVM, and tell people that that's the platform. You cannot be everything to everyone without collapsing under the weight.

markokocic 15y ago
Well, Scala is not the simplest language, but I'm not sure why having separate .Net backend will make the language more complex. After all, .Net and JVM are pretty similar at its core so that difference between the two shouldn't affect Scala the language, only Scala the compiler. As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
- danieldk 15y ago
  Right, you are paraphrasing my worry: there will be .Net and Java flavors Scala. Sure, the syntax will be portable, but programs do not only consist of syntax. C# in the .Net 1.0 era was very similar to Java. However, most of the domain-specific knowledge is not in the language, but in the associated class library and runtime. Usage patterns evolve with them. So, under the assumption that Scala.Net will get traction, in three years, people will be hiring Scala.Net and Scala(JVM) programmers. Educational programs will teaching two different flavors. Books will describe two different flavors. How does this help Scala or the Scala programmer? (Then there are more questions, such as: what does Scala.Net offer over C# (which is incorporating functional constructs) and F#?)
  - jbrechtel 15y ago
    IIRC 'Programming in Scala' doesn't talk much about the JVM.
  - markokocic 15y ago
    While we both agree what would happen, I don't see that as a bad thing. With core language being the same, lots of the skill will be portable. We have the same situation right now with C/C++, where people are hiring Windows C++ programmers and Linux C++ programmers. It doesn't seem to hurt that much C++ as a language. And C++ has even smaller "standard library" than Scala.
    - danieldk 15y ago
      C++ has a smaller standard library, but has easier interoperability with other languages. I see your point, but I do think it hurts C++ and C++ programmers. Programming C++ in Windows or programming C++ in a gtkmm context are very different. Even the most basic things are not standardized (unicode string handling, etc.). Middle ground does exist (Qt), but it does replace most of the STL and has some very basic weaknesses, like vectors that are limited to 2^31 − 1 elements on common platforms. So, again, I am seriously interested in what fragmentation buys you when porting to a platform that already has 1 1/2 functional languages, supported by its developer?
jcromartie 15y ago
This is basically the same reason that ClojureCLR has no traction.
- cema 15y ago
  One of the reasons. In general, I can see a low rate of acceptance of .NET among the crowd which has a high rate of interest in Clojure. I guess it is a case of avoiding Microsoft-dominated technologies by the open-source crowd.
  - code_duck 15y ago
    And the Microsoft crowd is sometimes reluctant to embrace non-Microsoft technologies.
    - cema 15y ago
      This is true, but I think the reasons are different. There has been a lot of usage knowledge created around the Microsoft platform(s), some supported by the community, but a lot still supported by the company. Moving in the open-source realm means losing a company's support, and I can see how those who are not used to it are uncomfortable with it.
      - code_duck 15y ago
        I don't see how that's too different than if a dedicated open source user was to move to using MS products. Replace 'Microsoft' with OSS and 'company' with 'community', and the statement is still true.
  - jcromartie 15y ago
    As someone who uses both, I'll gladly be a supporting data point for this hypothesis.
    - barighona 15y ago
      http://onlinepctvlink.blogspot.com/2011/07/nrl-rugby-st-george-dragons-vs-sharks.html http://onlinepctvlink.blogspot.com/2011/07/nrl-rugby-st-geor...

gtani 15y ago

This uses IKVM heavily, and it sounds like other people have tried running scala classfiles through IKVM http://groups.google.com/group/scala-user/browse_frm/thread/22c59173038a587a# http://groups.google.com/group/scala-user/browse_frm/thread/... and a LLVM backend project is also brewing http://news.ycombinator.com/item?id=2625405 http://news.ycombinator.com/item?id=2625405

ludwigvan 15y ago

The danger with this is, how long will it be supported? Can the Scala team ensure that it will not be deprecated in the future? With JVM, one is confident of future. I remember Microsoft letting go of the IronRuby developers, for example, has IronRuby's development stagnated as well? (I'm aware that the work is done by the Scala team in this case, though)

Fice 15y ago

Pragmatism over principle again; today's hacker culture is crippled.

rit 15y ago
Getting Shit Done trumps all things. The reality as well is that the majority of the .Net platform (with the exception of the Standard Libraries, I believe) are open ECMA Standards (See among others, #335).
- Fice 15y ago
  The reality is that .NET is a very probable patent trap for the FOSS community and Microsoft is trying hard to make us dependent on it. Unlike .NET, Java has a free implementation (OpenJDK) and any code derived from OpenJDK is granted Java patents. Apache is a different story as they are developing a Java implementation under permissive license, which means that Apache code could be used in non-free software (including .NET), that would make Java vulnerable to the "Embrace, Extend and Extinguish" strategy. That is what Apache is paid for by Microsoft. So my point is that supporting .NET is bad for the ideals of the free software community, yet it is good for pragmatic reasons as it could bring more users. And I have a strong impression that today pragmatism is favored over principle by the community, the decline of copyleft is also a sign of that.
  - macca321 15y ago
    So is it that you don't buy the Community Promise, or that you don't know about it? http://tirania.org/blog/archive/2009/Jul-06.html http://tirania.org/blog/archive/2009/Jul-06.html
    - Fice 15y ago
      FSF: Microsoft's Empty Promise (http://www.fsf.org/news/2009-07-mscp-mono http://www.fsf.org/news/2009-07-mscp-mono)
  - rit 15y ago

alexro 15y ago

How many companies that do both .Net and Java development and use Scala there are? Or how many will start developing in Scala if they're already proficient in .net? Definitely there will be some, but to base the compiler of such complexity around these few ... well, I just don't think it's worth the effort.

smcj 15y ago
Well, the Scala developers are currently moving their build system to Scala. This means they can fully bootstrap their language/compiler, library and build system from one source language. The .NET port has only added some minor changes to the compiler (which have actually uncovered a bug in the compiler implementation!) and most of the .NET backend works as a compiler plugin, just like the JVM backend or the LLVM backend.
icey 15y ago
I've always looked at Scala as a great language to go to if you don't want to be on the .Net stack. But if you're happy with the .Net ecosystem, the combination of C# and F# are very tough to beat. The tooling is great, and the languages are really well thought out. I don't really know what benefits there are to gain from using Scala on .Net other than the fact that it's cool that it could be done.

skrebbel 15y ago

To me, the obvious use case is not bringing the .Net platform to Scala developers, but bringing Scala to .Net developers. At my company, we do a large majority of our work in .Net languages, mostly C#. Being able to incrementally mix some Scala code into this for additional productivity, especially in the areas where Scala rocks (such as distributed / parallel processing, or in-language DSLs such as Scala's parsing library), sounds like a big win. Support for C# generics is a must for that, though; you need to be able to pass List<Banana>s around. Like other commenters said, the only danger is if the Scala guys would decide to stop supporting the CLR in the future again.

danieldk 15y ago
How does parallel processing in Scala "rock"? Can you point me to studies where Actors outperform, say OpenMP or Task Parallel Library? Does parallel processing on Scala compensate the overhead that Scala generally has over Java, C++, or in this case C#? I'd seriously like to know. I know that actors are good in some situations (distributed computing where you would normally use message passing), but statements such as the above can often be heard, but seem far to broad.
- smcj 15y ago
  Why and how should actors outperform OpenMP or TPL? They serve completely different goals. Scala ships by default with sequential, lazy and parallel collections and actors. Akka (akka.io) provides a different implementation of actors (which will replace the one in the standard library in the future), as well as Agents, STM, Transactors, ... for all your concurrency needs. Akka actors can actually outperform Erlang actors in core areas. Spark (spark-project.org) provides a (Hadoop-like) framework for distributed collections. Work is being done to make Scala collections run on GPUs, too. I would argue that Scala's toolbox is pretty diverse and complete when dealing with parallel and/or concurrent problems. Without facts I wouldn't claim that Scala is slower than Java/C++/C#. Scala beats the shit out of Java in situations where Java has to work with boxed types instead of primitives like in ArrayList<Integer>, enables people to write fully generic algorithms supporting any number type without speed penalty. Scala is certainly nicer than C++ because it just works and has far less weird corners or surprises. It lets you write code faster and gives you more time to actually optimize those places where it matters. C# is pretty much a kitchen-sink language with many features bolted on in a non-othogonal way, unlike Scala. The unreliable VM doesn't help, although value types and the thing Mono did with SIMD is certainly nice.

PaulHoule 15y ago

C# programmers don't have the sense of desperation that Java programmers do. C# has non-broken generics, (contra/co)variance, closures, method pointers, expression trees, type inference, value types (can implement complex numbers that take up just 8 bytes!) and many other little features that show that the language designers have some respect for programmers. If anything, C# is the language that Java refugees are looking for, not Scala.

smcj 15y ago
Well, some might actually want co-variant return types and "real" variance instead of the interface/delegate as well as non-broken array variance, real type inference, higher-kinded types (to not loose the collection type like in LINQ) and many things more. That said, yes, C# looks a bit more familiar to Java developers although it is more or less a C++ descendant. Additionally, most Java developers want to stay on the JVM, because it guarantees high performance, stability and maturity and has a wealth of well-known third party libraries.
- politician 15y ago
  If "most Java developers want to stay on the JVM, because X, Y, Z," then doesn't that support the OP reasoning that Scala on .NET is a solution looking for a problem?
irahul 15y ago
And C# programmers have F# to go to if they want to sample ML. I do not primarily program in C#, and I have done decent amount of Java. As far as languages are concerned, I find C# 4.0 a superior language to Java 6. I took a look at both Scala and F# - F# seemed simpler and more concise to me. One of my grudges is absence of a standard package manager for .net - Java has maven, ruby has gem, python has pip, C# has ?
- dennyferra 15y ago
  C# now has one called NuGet. Edit* Just wanted to clarify it is not specifically for C# but the .NET platform in general.

hkarthik 15y ago

It's an interesting project, but in my 6+ years of Enterprise .NET development, I've yet to work in a single shop that released a production .NET application that wasn't written in C# or VB.NET. Even F# seems to be very rarely deployed. It's hard to get excited about any new CLR-based language development when clearly the broader .NET community and the customer base could care less.

icey 15y ago
They're out there - we embed IronPython in our C# application, and are looking into using F# for some of the financial reporting our application creates. It is rare, but there are definitely uses to having multiple languages available on the CLR (and DLR).
ppog 15y ago
This is probably a fair point about the "enterprise .NET" community, which is by nature very conservative and closely aligned to core Microsoft technologies where the guarantees of support are strongest and the developer pool the largest. However we as a smaller shop have used F# on a couple of projects within the last year -- to embed an expression engine within an analytics product, and for the parser/analyser in our Sass plugin for Visual Studio. But I know I'd have struggled to get that technology choice into the last enterprise environment I worked in. So the lack of uptake may be more to do with the culture of "enterprise .NET" shops, more than the "broader .NET community."
- hkarthik 15y ago
  Well put. When I wrote "broader .NET community", I was mostly speaking to the vast majority of .NET developers, which are unfortunately stuck in typical Enterprise environments. There are definitely small shops out there doing interesting things and I love hearing about them!

sreque 15y ago

As someone who has recently learned C# and known Scala for a while, I am very impressed with what C# has to offer as a language. However, it is not nearly as well-designed as Scala. Microsoft has piled on feature after feature to the point where many C# are features either mostly deprecated and replaced by newer features or else do not mix well with new language features. Some examples include: -generic vs non-generic types. For instance, when using the Process class, you have to use StringDictionary. - Actions and delegates vs lambdas. This is made more painful by the fact that C# handles the void return type specially, so that there is no way to create a Func<void>. Also, it means that if you want to support higher order functions that support both a void and a generic return type you have to write two different functions. - ref and out parameters with lambdas. They just... don't mix! - out parameters vs 4.0 tuples. Really C# needed syntactic sugar for multiple return types long ago, but the idiomatic way to do this in C# is with a feature that simply does not play well with functional programming. There are other things that make Scala nicer as well. -In Scala every statement is also an expression and Scala has the bottom type, which again makes writing functional code much simpler. -Scala's collection's library is superior. It has functional collections and it's design enables overriding methods to have much more sensible static return types. -Scala's way of extending class functionality with implicits is more powerful and object-oriented than C#'s extension methods. In fact, Scala in general feels much more OO than C#. -Scala has a form of controlled multiple implementation inheritance (traits) that I really miss in C#. These are just the practical things I can think of on top of my head that I miss in C# versus Scala. On the other hand, I get the impression that C# was originally designed to be a more performant Java by hybridizing it with C++. It's richer value type system, the fact that class methods are non-virtual by deafult, and the ease by which one can drop into unsafe code mean that one can port a lot more performant C-style code to C# than on any JVM-originating language, which I think is C#'s greatest strength compared to Scala. Still, I think if people gave Scala a chance they would find it to be a very clean, productive, and well-designed language compared to C#. That alone may not be enough to convince people to switch to Scala in droves, but enough so that people who want to target both platforms will be willing to consider Scala as a solution rather than to use something like Mono.

smcj 15y ago
Couldn't say it any better, thanks!