
Scala comes to .Net - markokocic
http://www.scala-lang.org/node/10299
======
PaulHoule
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.

~~~
irahul
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
C# now has one called NuGet.

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

~~~
mattmanser
In typical MS style though it is incredibly over engineered while not quite
doing the job.

~~~
skrebbel
Could you elaborate? (true interest, I didn't downvote)

~~~
mattmanser
When you first come across it it looks like they're console commands. Yay! You
go, the light has been seen at MS! After mucking round with cmd and then power
shell for a few minutes you realize, well, no, they're not. There's yet
another window added to visual studio to run the commands and it installs a
new directory and a crapton of pointless files in your project directory to
boot. Woo. Like we needed more of them. And just to be extra useful it puts
yet another option in the already vastly overcrowded and poorly organised
right-click menu of projects.

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.

~~~
ern
You mention the complexity of the ASP.NET membership system. I've always found
it to be quite straightforward (unless you write your own providers I guess).
Where are the pain points for you?

~~~
teyc
It was quite difficult for me when I first tried to pick up ASP.net. In
retrospect, I don't think the problem is how difficult ASP.net provider system
is, but the absence of assertiveness in the voice in tutorials. They tend to
say, you an do it this using Forms Authentication, or Windows or Passport.
Which is all true, but presents too many options to someone trying to find
their way around a new system.

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

~~~
droz
>> so that there is no way to create a Func<void>

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

~~~
ppog
Func<Action> would be a function that takes no arguments and returns an
Action. The desire is to be able to specify void as the return type of a Func,
so that you can use Funcs for all callbacks, instead of having to use Funcs
for callbacks that return a value and Actions for callbacks that don't.

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

~~~
danieldk
_Why and how should actors outperform OpenMP or TPL? They serve completely
different goals._

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.

~~~
smcj
>>> Is driving a car better than eating a banana?

>> 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...](http://www.azavea.com/blogs/labs/2011/06/scalas-numeric-type-class-
pt-2/)

~~~
danieldk
First, I am reacting to the original commenter, and pointing out that your
post does not answer my question to the original commenter.

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.

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

~~~
markokocic
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
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?

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

~~~
agscala
S# :)

------
ludwigvan
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)

------
gtani
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/...](http://groups.google.com/group/scala-
user/browse_frm/thread/22c59173038a587a#)

and a LLVM backend project is also brewing

<http://news.ycombinator.com/item?id=2625405>

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

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

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

~~~
ppog
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
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!

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

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

~~~
rit
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
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
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>

~~~
Fice
FSF: Microsoft's Empty Promise (<http://www.fsf.org/news/2009-07-mscp-mono>)

