Scala comes to .Net

by markokocic • 15 years ago

95 70 15 years ago

wccrawford• 15 years 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• 15 years 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• 15 years ago

Yes. Pretty sure that hasn't been done before! :D

agscala• 15 years ago

S# :)

microtonal6• 15 years 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.

markokocic2• 15 years 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.

microtonal6• 15 years 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#?)

jcromartie3• 15 years ago

This is basically the same reason that ClojureCLR has no traction.

cema2• 15 years 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.

gtani• 15 years 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/...

and a LLVM backend project is also brewing

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

ludwigvan• 15 years 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)

Fice6• 15 years ago

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

rit2• 15 years 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).

Fice6• 15 years 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.

virmundi• 15 years ago

Can you go into some details on this?

Fice6• 15 years ago

Yes, please see my reply above.

kenjackson• 15 years ago

The hacker culture is all about doing what you can, and saying "screw you" to anyone who tries to tell us what is principled or not. If you want to talk principles go to church.

Fice6• 15 years ago

So if I kill people and say "screw you" to anyone who tell me that this is wrong am I a hacker?

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

shriphani• 15 years ago

Who sets these principles? I ask because FSF has bashed Apple and MS at various points in time. If the FSF is writing the religious-book here, then you're not supposed to work with the cloud, you're not supposed to use to chromeOS notebooks and boy you should really go dump those smartphones since they're either proprietary or open-but-not-quite.

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.

Fice6• 15 years ago

Being a part of the hacker culture means sharing the hacker ethics, including the principle of information-sharing, which is the base of the FSF philosophy. These principles are not set by someone, there are what is meant by the word "hacker". If you do not consider these principles to define what the hacker culture is, then we are talking about different "hacker cultures". I use the common programmer subculture meaning of "hacker": http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)

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.

shadowfox• 15 years ago

It is indeed sad that everybody does not meet your expectations

alexro• 15 years 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.

smcj7• 15 years 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.

icey3• 15 years 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.

skrebbel4• 15 years 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.

microtonal6• 15 years 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.

smcj7• 15 years 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.

skrebbel4• 15 years ago

> How does parallel processing in Scala "rock"?

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.

PaulHoule2• 15 years 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.

smcj7• 15 years 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.

politician2• 15 years 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• 15 years 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• 15 years ago

C# now has one called NuGet.

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

jcromartie3• 15 years ago

C# has copy/paste or zip files from http://www.codeproject.com/

Edit: this is a joke

PaulHoule2• 15 years ago

.NET's definitely got the weakness that there's less of an Open Source community around it. There certainly are some good things out there, but nothing like Java.

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.

pragmatic• 15 years ago

Very true.

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

smcj7• 15 years ago

The state of IDE support has pretty much changed since a year ago.

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.

bborud• 15 years ago

...and when Larry Ellison is done having his way with Java and has alienated the entire community, the .Net community is going to start looking almost ... appealing.

hkarthik2• 15 years 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.

icey3• 15 years 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).

ppog2• 15 years 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."

hkarthik2• 15 years 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!

_ivvf• 15 years 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.

smcj7• 15 years ago

Couldn't say it any better, thanks!

droz• 15 years ago

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

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

ppog2• 15 years ago

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.

nigelsampson• 15 years ago

Most of the your examples look like they're caused by the base class library not keeping up with language advancements. Which I agree can be a real issue.

Scala comes to .Net

Related Stories