Metacircular thoughts

February 11, 2007

F# vs. Scala: an uninformed comparison

Filed under: Scala — metacircular @ 10:35 pm

If you want to do functional programming but also actually get stuff done, you don’t have many options. Pretty much your options are F#, Scala, and BusinessObjects’ new CAL. I don’t really want to write Haskell-like code and too much of what I tinker with is inherently stateful and imperative, so that leaves F# and Scala for me. Scala and F# are pretty much analogues of one another, but with different target virtual machines.

Here is, from what I can tell, are some of the differences and similarities between F# and Scala.

  • F# has better IDE integration via Visual Studio. However, this is like saying that a certain kind of boat is really good for cruising around in the sewers. The Visual Studio IDE is an orgy of complex, useless stuff. Then again, it has better REPL integration, creating more of an interactive feel. Scala’s Eclipse plugin, as raw as it is, is for an open IDE whereas Visual Studio is proprietary.
  • F# has far less support for objects and object-oriented programming. Scala wins big on this. This isn’t entirely fair, though, as unifying object-oriented and functional programming is one of the central goals of the Scala project. However, Scala also has this remarkable ability to look like Java if you want it to, down to superfluous semicolons and superfluous ()’s when you call a function that takes no parameters.
  • They have roughly comparable performance.
  • Since F# talks to .NET, it’s going to be better for creating Windows GUI apps. I know there’s SWT, but it really doesn’t compare. Wishing for cross-platform UIs is a pipe dream. The sooner you realize this, the better.
  • F# targets .NET which, while it certainly isn’t going anywhere anytime soon, is proprietary. Of course, this was true of Scala up until a few months ago.
  • F#, being more ML-like than Scala, has more of a minimal lambda calculus-y feel to it the way OCaml, Standard ML, and Scheme have. F# appears to be a considerably simpler language.
  • Both are powerful, expressive, pragmatic languages that are far superior to C# or Java.

19 Comments »

  1. How about comparing them to erlang? Erlang is also functional but not purely so. It has it’s own open source VM. It’s been used to build real life applications which is more then you can say about either scala or F#.

    Comment by malcontent — February 11, 2007 @ 11:24 pm | Reply

  2. It’s true that there are Erlang codebases that are very thoroughly battletested and are far, far larger than the largest Scala codebases in existence. Erlang is very nice to use and vastly simplifies distributed computing. The combination of message passing and symbolic support is easy like Sunday morning.

    In fact Scala has a library that implements Erlang-style concurrency. David Pollak has been tinkering with it a lot.

    The main reason I didn’t include Erlang is that I don’t think it’s all that useful outside of its niche, which is fault-tolerant real-time distributed telecom systems. I think my main indictment of it is its lack of support for strings. Granted, Java’s string class is pretty weak compared to what’s available in Python and Ruby, but at least there’s baked-in Unicode support all the way down. If I were going to write a network server (an enterprise calendar server, say), I’d give Erlang a long hard look. Otherwise I wouldn’t want to use it.

    However, David thinks having an Erlang port of Mnesia would be very cool. I’d look into it but I’m too much of a wuss to implement ACID transactions.

    Thanks for commenting!

    Comment by metacircular — February 11, 2007 @ 11:33 pm | Reply

  3. I think you are also missing Nemerle (www.nemerle.org).

    It targets .NET, and has a syntax far closer to Scala/Java/C# than to ML/OCaml. No decent REPL last I checked.

    Comment by Alexey — February 12, 2007 @ 3:24 am | Reply

  4. Then, there’s Mozart/Oz. It has a lot in it.
    The underdog.
    Some claim to have used it in production systems.
    But, hey, people jumped on the RRuby bandwagon when it was a piece of s**t.

    Comment by JJ — February 12, 2007 @ 7:04 am | Reply

  5. We have been using F# a lot over the past 9 months and I’ve been evaluating Scala and Haskell for a couple of months now (without writing anything significant).

    F# is a faithful functional programming language with a good implementation on top of a solid platform (that has native support for functional programming languages).

    Scala is quite different. Firstly, it is a long way from being a modern functional programming language. Type inference is only partly supported in Scala. The type system seems to be very weak. The JVM lacks essential constructs for functional programming languages (primarily tail recursion).

    For anyone interested in learning about functional programming under Windows, I would definitely recommend F# first. For Mac OS X and Linux I would recommend OCaml.

    Comment by Jon Harrop — August 24, 2007 @ 3:03 pm | Reply

  6. I can’t comment on F# because I haven’t spent any time with it. The general commentary is that it’s very OCamlish, and that’s a good thing.

    I have been spending time with Scala, though, and would like to refute at least one point made by Jon. Scala does support full tail recursion optimization. That’s because the JVM bytecode has “goto”, which is all you need for TRO. That said, Scala does not support general tail call optimization on the JVM. The CLR certainly got that one right by including a bytecode for TCO. It’s possible that Jon understands the difference and just mistyped.

    Jon also says that Scala’s type system is “weak.” Unfortunately, that word is so overloaded that it’s hard to know what he means and so I can’t refute it nor support it. I can say that Scala supports sealed case classes to emulate Haskell style algebraic data types – and you can make any class support pattern matching. It has parametric types with variance annotation, existential types, explicit self typing, structural typing, type members, user defined implicit type conversion, type aliasing, Java/C# style subclassing, and mix-ins. On the downside, and perhaps what Jon meant by “weak”, it has explicit casting and null – primarily to aid in Java/C# integration.

    Hmmm, clicking Jon’s link takes you to a page selling F# journals. I’m just saying… :-)

    Comment by James Iry — September 7, 2007 @ 8:16 pm | Reply

  7. 1. The IDE integration you boast for Scala in a more recent blog post is based on IntelliJ IDEA, AFAIK. That IDE is more expensive than a Visual Studio Standard Edition which is all that is required for F#, considering F# integration into VS isn’t as deep/advanced as the first-class-citizen .NET languages like C# and Visual Basic.

    2. F# is not trying to be another be-all-end-all type of programming language. It’s a Functional Programming language and there is no need to try to make it do everything that other languages do. If you need an OOPL, then you have other choices – hardly limited, either :)

    3. ( Nothing to Say )

    4. There’s Swing and SWT on the Java platform (you speak as if one doesn’t exist, or is not a factor). Also, I think there are better choices for creating client applications on .NET even though F# has the capability.

    5. Certainly you do not believe that .NET isn’t going anywhere? That is probably the most ignorant/ill-conceived statement I have ever read on a weblog…

    6. F# is more ML like Scala because it is an ML derivative. It is designed to be as close to ML as possible with the features that Microsoft has tacked-on to it (no doubt for the better). I don’t see where this has any bearing. Also, if the languages were designed different and for different purposes (possibly), why even bother comparing them? I don’t consider F# to be “finished”. It will evolve the same way other languages such as VB, C#, C/C++, Java, and Delphi has.

    7. Languages are only superior to other languages when you try to use them for solutions that are in their sweet spot. I’m sure Assembly Language is very powerful, but you don’t see developers writing every type of applications with it.

    This blog is a joke, and admittedly “uninformed”. If you are going to make comparisons (which are really supposed to be helpful) please keep with the facts and leave the bias and anti-Microsoft sentiments out of it.

    And any IDE based on Eclipse is worse than Visual Studio by default.

    Comment by Hrm... — November 29, 2007 @ 11:42 am | Reply

  8. “more ML like *than* Scala”

    Comment by Hrm... — November 29, 2007 @ 11:43 am | Reply

  9. Scala has both a .NET and a JVM binding.

    The ,NET binding is documented here: http://www.scala-lang.org/docu/clr/index.html

    Comment by Jerry — January 19, 2008 @ 12:00 am | Reply

  10. F# works perfectly on Mono. That’s all i will say.

    Comment by Eugene — January 23, 2008 @ 10:50 am | Reply

  11. “And any IDE based on Eclipse is worse than Visual Studio by default.”

    That’s the most uninformed thing a Java / .NET programmer could say.

    Comment by jau — March 12, 2008 @ 11:59 am | Reply

  12. I wish the comment “F# has far less support for objects and object-oriented programming. Scala wins big on this” was a little more fleshed out. What OOP features are missing from F#?

    Comment by yahwehofnod — July 6, 2008 @ 4:26 pm | Reply

  13. @Hrm…

    >This blog is a joke, and admittedly “uninformed”. If you are going
    >to make comparisons (which are really supposed to be helpful) please
    >keep with the facts and leave the bias and anti-Microsoft sentiments
    >out of it.
    >
    >And any IDE based on Eclipse is worse than Visual Studio by default.

    Why so hypocritical?

    Comment by Zack — October 11, 2008 @ 12:10 am | Reply

  14. >Certainly you do not believe that .NET isn’t going anywhere?
    >That is probably the most ignorant/ill-conceived statement I
    >have ever read on a weblog…

    The phrase “isn’t going anywhere” does not mean what you think it means. Google it and you’ll get a better idea of how it should be interpreted.

    Comment by Zack — October 11, 2008 @ 12:21 am | Reply

  15. > The phrase “isn’t going anywhere” does not mean what you think it means.

    Agreed.
    Zack meant that .Net is here to stay (i.e. it isn’t going away anytime soon)

    > That’s the most uninformed thing a Java / .NET programmer could say.

    Why? I use both and Eclipse is cool and all but it’s slower than VS on all my machines and it doesn’t do anything extraordinary that VS doesn’t do as well.

    > F#, being more ML-like than Scala

    That’s a matter of taste. Some of us are not in love with ML at all.
    I like F# and I’ve been using it for months for its functional traits, not for its resemblance of ML or OCaml, I couldn’t care less about that.

    > F# has far less support for objects and object-oriented programming

    As far as what? so far I’ve been able to do everything I wanted with F#

    Comment by Steven — December 3, 2008 @ 8:17 pm | Reply

  16. After reading “Expert F#”, I also haven’t noticed anything missing from its OOP support — it looked great to me. Maybe something was missing a couple years ago when this blog post came out…?

    F# isn’t listed on Mono’s homepage for some reason, but it works on Mono. The compiler and core library are also planned as shared source releases, according to this blog post:

    http://blogs.msdn.com/dsyme/archive/2008/12/10/fsharp-to-ship-as-part-of-visual-studio-2010.aspx

    Comment by Eli Ford — December 29, 2008 @ 4:15 pm | Reply

  17. I follow your posts for a long time and should tell you that your posts always prove to be of a high value and quality for readers.

    Comment by How to Get Six Pack Fast — April 15, 2009 @ 6:52 am | Reply

  18. I see Scala as being an easier sell than F# to people with an OO background. The problem with just about any F# book you pick up, including the excellent one written by Jon Harrop, is that they contain an obligatory chapter on OO and spend the rest of their time illustrating the solution of problems in a purely functional way. This definitely made it hard for me to do much with F#, as I sensed that the best practice approach was to compose things in a functional manner first and bring OO in much later if at all, which is the opposite of how I like to think.

    Scala on the other hand enhances the capabilities of Java’s OO system by including traits, better encapsulation mechanisms, case classes, etc. You could use Scala for these features and never do anything remotely functional, and you would develop better code than with Java/C#, especially given the legibility that implicits bring to the table. With the ability to also work in a functional manner, one can gradually pick up both paradigms at whatever pace is most natural.

    One thing that I have to say when it comes to F# is that I find the culture encourages less readable code than does Scala. Having great HM support seems to mean that (and again, this is going from the books) F# programmers do not write many type annotations. The fact that these are required in Scala at least for parameters to methods has meant that it is easier for me to reason about what my code means after being away from it for some time, which was not the case in F#.

    Comment by Steve — June 8, 2009 @ 11:18 am | Reply

  19. [...] Scala is all about the OO and F# is more about writing in a functional perspective. But here’s an article from 2007 that may give you a better idea or Brandon Werner’s article comparing the functional [...]

    Pingback by Learning Scala from a Java perspective | Thushan Fernando Uncut — October 1, 2009 @ 1:47 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a comment

Blog at WordPress.com.