Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

F# and Scala are both functional programming langugages that don't force the developer to only use immutable datatypes. They both have support for objects, can use libraries written in other languages and run on a virtual machine. Both languages seem to be based on ML.

What are the biggest differences between F# and Scala despite the fact that F# is designed for .NET and Scala for the Java platform?

share|improve this question
1  
If you can vote and think this is a useful question or it have useful answers below, please vote up. StackExchange sites need votes to build a good community. You can give 30 votes per day, don't waste them. Specially users with high reputation and low counting votes given please read this: meta.programmers.stackexchange.com/questions/393/… –  bigown Oct 5 '10 at 22:27
    
functional programming langugages that don't force the developer to only use immutable datatypes - are there any, except maybe toy languages? –  Ingo Oct 6 '11 at 10:43
    
@Ingo, if you think that ML and Ocaml don't qualify as functional programming languages because they allow mutability, maybe you should adjust your definition! –  Frank Shearar Jan 14 '12 at 15:20
2  
+Frank, you must have misunderstood: I mean, even Haskell has mutable data types. Hence, I'd still like to know which languages @Jonas has maybe in mind that would force one to use only immutable datatypes? –  Ingo Jan 14 '12 at 16:21

3 Answers 3

up vote 51 down vote accepted
+50

Major Differences:

  • Both Scala and F# combine OO-imperative programming and functional programming into one language. Their approach towards unification of paradigms is vastly different though. Scala tries to fuse the two paradigms into one (we call it object-functional paradigm), whereas F# provides the two paradigms side by side. For example, algebraic data types in F# are purely functional constructs with no OO'ness in them whereas ADTs in Scala are still regular classes and objects. (Note: In the process of compilation to CLR bytecode, even F# ADTs become classes and objects but they are not visible to F# programmer at the source level.)

  • F# has full Hindley-Milner style type inference. Scala has partial type inference. Support for subtyping and pure-OO-ness makes Hindley-Milner style type inference impossible for Scala.

  • Scala is much more minimalistic language than F#. Scala has a very small orthogonal set of constructs that are re-used throughout the language. F# seems to introduce new syntax for every little thing, thus becoming very syntax heavy as compared to Scala. (Scala has 40 keywords, whereas F# has 97. That should tell you something. :-)

  • F# being a Microsoft language has an excellent IDE support in the form of Visual Studio. Things are not so good on the Scala side. Eclipse plugin is still not upto the mark. Same goes for NetBeans plugin. IDEA seems to be your best bet at the moment, though it doesn't even come close to what you get with Java IDEs. (For Emacs fans, there's ENSIME. I have heard a lot of good things about this package, but I haven't tried it yet.)

  • Scala has far more powerful (and complex) type system than F#.


Other Differences:

  • F# functions are curried by default. In Scala, currying is available but not used very often.

  • Scala's syntax is a mix of that of Java, Standard ML, Haskell, Erlang and many many other languages. F# syntax is inspired by those of OCaml, C#, and Haskell.

  • Scala supports higher kinds and typeclasses. F# doesn't.

  • Scala is much more amenable to DSLs than F#.


PS: I love both Scala and F#, and hope they become predominant languages of their respective platforms in the future. :-)

share|improve this answer
3  
This answer perpetuates several misconceptions. I'll enumerate each in turn. You said "algebraic data types in F# are purely functional constructs with no OO'ness in them" but algebraic datatypes in F# are just class and, in particular, they support augmentation with OO instance/static members and properties. –  Jon Harrop Dec 27 '10 at 13:48
4  
You say "Scala tries to fuse the two paradigms into one (we call it object-functional paradigm)" but Scala lacks general tail call elimination and, consequently, any non-trivial functional code (including almost all conventional functional idioms such as continuation passing style and untying the recursive knot) are prone to stack overflows in Scala and, therefore, are practically useless. –  Jon Harrop Dec 27 '10 at 13:50
3  
@JonHarrop: Scala doesn't treat ADTs specially. They are treated just like regular classes. Thereofre Some(2) in Scala has type Some[Int] and not Option[Int] which is undesirable IMO. F# on other other hand has a special syntax and treatment for ADTs, and can thus correctly infer type of Some 2 as int option. So F# encoding of ADTs is better than that of Scala's (IMO, of course). I did not try to imply that it's inferior, and I am sorry if it came across that way. –  missingfaktor Oct 6 '11 at 10:55
5  
@JonHarrop: The lack of TCO in JVM hasn't bothered many Scala developers. Trust me, it's not as big an issue as you seem to think. Most of the time, we are using higher order functions, instead of explicit recursion. And most higher order functions in Scala are implemented in terms of loops, and not recursion. So, lack of TCO becomes close to immaterial. –  missingfaktor Oct 6 '11 at 10:57
2  
@JonHarrop: When you need to extend the collection classes with new functions, you can most of the time leverage existing higher order functions. Very rarely, if ever, you may have to write a function from scratch. In such cases, if Scala's limited support for TCO (yes, it has some!) fails to work for you, go for the loops. Since the mutability in this case is local, the function is still pure, and you lose nothing. –  missingfaktor Jan 14 '12 at 14:56
  • F# is settled on functional aspects while scala is based on object-oriented aspects.
  • F# has better IDE support with Visual studio while Scala's eclipse plug-in is for open source IDE and comparatively slower.
  • 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.

Thanks


Ayush Goyal

share|improve this answer
    
+1: This is the most accurate answer here. –  Jon Harrop Dec 27 '10 at 14:01
2  
"F# appears to be a considerably simpler language." << No, it is not. It is way larger than Scala. I should write an article on this subject some time. –  missingfaktor Jan 15 '12 at 5:05
2  
"Scala is based on object-oriented aspects." << Wrong. Scala tries to fuse OOP AND functional programming. I personally very rarely use its object-oriented features. Most of what we do is purely functional. –  missingfaktor Jan 15 '12 at 5:06
    
@missingfaktor: "It is way larger than Scala". How big are the grammars? –  Jon Harrop Nov 4 '13 at 20:00

One small but important points is the license: Scala is BSD (pretty much the most permissive free software license there is), F# used to be "Microsoft Research Shared Source license agreement" but is a commercial product nowadays (according to @Lorenzo below, although I couldn't find more specific license agreements anywhere).

share|improve this answer
3  
Actually, F# is now open source and Scala is now a commercial product of Martin Odersky's company Scala Solutions. –  Jon Harrop Dec 27 '10 at 13:59
3  
@Jon Harrop: I think Scala Solutions is selling just Scala-related tools, services, training etc. The language itself still seems to be under the BSD license. –  Joonas Pulakka Dec 27 '10 at 14:18
2  
@Joonas: Exactly, the same is true of F#. –  Jon Harrop Dec 27 '10 at 15:51
1  
@JonHarrop: Scala remains open source. Please do not spread misinformation. –  missingfaktor Jan 14 '12 at 21:10
2  
@missingfaktor: I didn't say Scala was closed source. –  Jon Harrop Jan 14 '12 at 22:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.