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.

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 ?

Edit* Just wanted to clarify it is not specifically for C# but the .NET platform in general.

I love visual studio and C#. But NuGet's pretty pants, it just feels like you're being treated like a child.

To me this just smacks of the overkill of the asp.net membership system to me. Vastly overcomplicated to do a simple job. Maybe I'm just getting cynical in my old age and it's time to switch to linux. There's lots of little things that bug me in .Net though so it's probably just one of my pet peeves. For example I've always detested the obsession asp.net has with ~ that for the most part is totally and utterly pointless.

With a lot of things MS seem to approach the problem with the most complicated use case in mind rather than the simplest.

Sounds much like a matter of taste then, though. I much prefer clicking a button over typing a command (f.ex. tortoisegit over git, explorer over bash mv/cp/etc).

I spent a lot of time in the last week implementing an internal DSL in Java which in turn got me meditating on Scala.

I'm not sure that the increased fluency of Scala syntax is really a win for internal DSLs. My fear is that the fluent syntax depends a lot on fine details of the language; you could make some beautiful examples for the DSL's documentation, but take one step away from that and the user of the DSL has to deeply understand Scala's corner cases.

One thing that could be good about Scala, like ML derivatives is pattern matching.

Somebody with a lot of OO experience who's used to building things in an OO way might have a negative impression of pattern matching for polymorphism as opposed to conventional polymorphism. However, if you're building out an AST and you might want to process it in different ways, the pattern matching paradigm could be much better. For instance, if you've got something like a C# expression tree, you might want to 'interpret' it in the obvious way, or compile it to Java bytecodes, or compile it to a SQL query string, or do any of a number of different things. Pattern matching would provide a lovely way to do this.

Edit: this is a joke

I used Scala on a project a year or so ago. I needed/wanted to target the JVM. However, after looking at Java the language, I realized how far it was behind C# now. (I hadn't used Java in several years after going to work for a Microsoft shop).

Scala was fairly easy to learn, the new features of C# really coalesced nicely with the Scala language, so I didn't feel like I had to learn much.

There are some nice features of Scala (var/val immutability, etc) that would be nice to see in C#.

I think Scala adoption in the .NET community may be hampered by 1) continual improvements in the c# language and 2) the F# language.

The F# language in particular because it has full IDE support.

The Achilles heel of Scala was lack of really good IDE support. Coming from C#/Visual Studio, working with Netbeans and the Scala plugin was somewhat frustrating...it wasn't quite ready for prime time. (Considering it was the work of one person, it worked very well but had a few issues).

IntelliJ pretty much rocks, Eclipse is done by the Scala team itself (no idea about Netbeans, though). While Scala IDEs haven't reached the level of maturity or the wealth of features of Java IDEs, they have useful features even Java IDEs lack.

I guess the .NET port is mainly for people wanting to keep writing Scala regardless if they are targeting the JVM, the CLR, browsers with JavaScript/GWT or the LLVM.

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.

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.

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.

Actually, in this case I was mostly referring to the parallel and distributed collections. And stuff like coding a for comprehension that can be transparently spread over multiple cores or even boxes.

I don't know enough about the actors stuff to make a good statement about it.

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.

If I may be so bold, without facts I wouldn't claim the C# VM is unreliable or that features are added without thought.

Show us numbers. That was the main request of my comment, and you come with a list of libraries? We hear all the time how great Scala is with respect to parallel computing. Show me some good examples, where it beats C++ or C# with TPL, say doing number crunching.

It's all to easy to repeat a mantra (parallel programming in Scala rocks), but it has been proven correct rarely. Given such statements, I would either expect it to be much easier to parallelize programs in Scala (as opposed to, say, adding OpenMP pragmas) or would expect parallelized programs to be much faster. Neither seem to be true.

>> They serve completely different goals.

> Show us numbers.

That makes sense, doesn't it?

> That was the main request of my comment, and you come with a list of libraries?

Well, after you failed to even tell concurrent and parallel computing apart, I assumed giving you an overview first would be beneficial.

Maybe you could use the links I already gave you or use Google. For instance, here is an additional link I found pretty easily: http://www.azavea.com/blogs/labs/2011/06/scalas-numeric-type...

Second, I do know the difference between concurrency and parallelism (since I use the latter a lot, and the former in the rare occasion of writing GUI programs). Anyway, your ad hominems do not serve the discussion.

Third, mentioning 'actors' and OpenMP is one sentence was poking a bit of fun at the overly broad statements often made by fans of Scala (and Erlang) about what Actors will do. But the next time I will leave my sardonicism at the door.

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.

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.

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#?)

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.

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?

Things in the Java standard library will work on .NET. Scala, too. If Scala uses .NET classes, this will also work. What's the problem?

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)

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

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.

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.

-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.

Does Func<Action> not achieve what you are after?

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.

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."

There are definitely small shops out there doing interesting things and I love hearing about them!

With the ability to use .NET or the JVM... I mean, wow.

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.

In that same vein, code inside a car's sensors isn't open sourced and Toyota had a rather messy couple of months because of it. So boycott cars too ? Build your own car ?

I really don't get the excuses people come up with to complain about people getting shit done. A "principles based" fight is being fought in politics all the time; fat load of good that's doing.

Sharing the same ethics means having similar views of good and evil. Seeing something as evil does not mean you must boycott it, yet it is logical though not always practically possible to avoid what you consider to be evil.

That is nihilism. If it is called a culture, there must be ethics. For instance, information-sharing is an important hacker ethic: http://www.catb.org/jargon/html/H/hacker-ethic.html