74

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?

Jonas
  • 14,867
  • 9
  • 69
  • 102
  • 2
    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: http://meta.programmers.stackexchange.com/questions/393/asking-better-questions – Maniero Oct 05 '10 at 22:27
  • 1
    `functional programming langugages that don't force the developer to only use immutable datatypes` - are there any, except maybe toy languages? – Ingo Oct 06 '11 at 10:43
  • 1
    @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
  • 5
    +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

4 Answers4

70

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

missingfaktor
  • 3,906
  • 1
  • 24
  • 31
  • 1
    Best answer here. +1 – Chankey Pathak Oct 15 '10 at 18:31
  • @missingfaktor: Welcome :) – Chankey Pathak Oct 15 '10 at 18:34
  • Good answer, but I would say the syntax of F# is OCaml-ish rather than ML-ish, in fact F# even supports OCaml-compatible syntax: http://www.ctocorner.com/fsharp/book/ch2.aspx . (Just to be pedantic OCaml is ML-family.) – Jared Updike Oct 15 '10 at 21:47
  • @Jared: Edited :) – missingfaktor Oct 16 '10 at 02:00
  • 7
    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. – J D Dec 27 '10 at 13:48
  • 7
    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. – J D Dec 27 '10 at 13:50
  • 2
    You say "Scala has 40 keywords, whereas F# has 97" but F# has only 63 keywords by my count, not that it is representative of anything. – J D Dec 27 '10 at 13:52
  • 2
    You say "F# syntax is completely OCaml-ish" but F# differs from OCaml syntax in many ways. The defacto-standard #light syntax in F# is completely un-OCaml and more like Python or Haskell. The syntax for objects and classes in F# is also completely different from OCaml's. Even the syntax for array access is different... – J D Dec 27 '10 at 13:54
  • One additional important difference is that Scala has implicit conversions, which allows to simulate Haskell style type-classes. – Landei Oct 06 '11 at 10:10
  • 4
    @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 06 '11 at 10:55
  • 10
    @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 06 '11 at 10:57
  • 1
    @JonHarrop: I picked the keyword count from [this blog post](http://carlosqt.blogspot.com/2010/07/how-many-keywords-do-you-type-in-your.html). Show me an authoritative source that differs with this, and I'll update my answer accordingly. – missingfaktor Oct 06 '11 at 10:59
  • @JonHarrop: I find F# syntax very close to that of OCaml's. I am familiar with Haskell and Python as well, and I don't see the similarity. Yes, the syntax (and semantics) of F# when it comes to OOP differs completely from that of OCaml's. Still IMO their syntaxes are close enough to justify my statement. – missingfaktor Oct 06 '11 at 11:02
  • @Landei: Yes, I did mention typeclasses. :-) – missingfaktor Oct 06 '11 at 11:02
  • @missingfactor: I need new glasses 8-) – Landei Oct 07 '11 at 13:23
  • 1
    @missingfaktor: "The lack of TCO in JVM hasn't bothered many Scala developers". When TCO fails in F# it really bothers me. – J D Jan 14 '12 at 14:01
  • @missingfaktor: "Show me an authoritative source that differs with this, and I'll update my answer accordingly". I've no idea but I wonder about the relative sizes of the parsers/grammars. – J D Jan 14 '12 at 14:01
  • 1
    @missingfaktor: "I don't see the similarity". F#, Haskell and Python are indentation sensitive. OCaml is not. – J D Jan 14 '12 at 14:02
  • 1
    @JonHarrop: We use Scala at production. And the code is purely functional. Not a single variable, and yet we haven't been hit by lack of TCO this far. Scala standard library has far larger number of higher order functions than F# does. See for example: [scala.collection.immutable.List](http://www.scala-lang.org/api/current/scala/collection/immutable/List.html). These functions cover most use cases. They are internally implemented with loops, but that doesn't bother us. (contd...) – missingfaktor Jan 14 '12 at 14:54
  • 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
  • @JonHarrop: Regarding syntax, thanks for the info. I will update the answer. – missingfaktor Jan 14 '12 at 14:56
  • 2
    Looks like a good opportunity for Jon Harrop to once more tell the TCO myth. – Ingo Jan 14 '12 at 16:23
  • @missingfaktor: "we haven't been hit by lack of TCO this far". That's very interesting. I've seen people bitten by TCO quite often using F# even though it has far better support for it than Scala does. In particular, nested calls to `Seq.append` can stack overflow upon enumeration and some calls like `[1..1000000].GetHashCode()` crash the whole .NET application immediately. – J D Jan 14 '12 at 20:05
  • @missingfaktor: Does `List.range(0,1000000).hashCode()` work? – J D Jan 14 '12 at 20:19
  • @JonHarrop: Works just fine. http://paste.pocoo.org/show/534866/ – missingfaktor Jan 14 '12 at 21:08
  • 3
    As a note to the curious reader, there are 63 *used* keywords in F#. 97 is the sum of keyword count (63) and reserved token count (34). – henginy Feb 21 '12 at 05:23
  • 8
    I feel like this whole answer is a little biased towards Scala. For example *Scala is much more minimalistic language than F#* which seems to go against his argument/later point of a more complex type system. – Adam Gent Feb 07 '13 at 16:33
  • @AdamGent, I believe minimalism is one of the key aspects of Scala's design. An example: F# has distinct concepts of classes and discriminated unions. Scala's object model handles both seamlessly together. You can find many more examples like these. – missingfaktor Feb 08 '13 at 08:51
  • 2
    I guess its the semantics of the word minimalism. Haskell is thus more minimal than Scala. The FP-OOP mariage I think is by definition much more complicated than say pure FP. F# has OOP mainly for compatibility with .NET. Scala embraces it. Scala's actor model is IMHO more complicated than F# async workflows. The syntax of the language by your definition maybe more "minimal" but the languages as a whole can't be compared like that. – Adam Gent Feb 09 '13 at 13:11
  • Haskell is certainly much more minimal than Scala, no doubt there. – missingfaktor Feb 09 '13 at 13:28
  • 1
    About actor model, it is not built into Scala the language. It's purely a library. You might want to read up more on that. Scala also has futures in its library, a concept that's closer to async workflows than actors are. – missingfaktor Feb 09 '13 at 13:30
  • You might want to read up more on Scala's implementation of Actors :) If it was just a library you could just emulate it in Java but there is special byte code generation going on. The compiler most certainly does special things for Actors. They provide green threads and continuation like behavior that is not possible in Java. I'm almost certain its not just a tack on library but I can't find a reference so... maybe I'm wrong. – Adam Gent Feb 10 '13 at 00:08
  • Hmm maybe your right I could have sworn that Scala generated Kilim like bytecode but maybe they haven't implemented that yet. – Adam Gent Feb 10 '13 at 00:14
  • 1
    Also Futures are not closer... Promises are closer to async workflows. See http://stackoverflow.com/questions/5579602/what-is-the-scala-equivalent-of-fs-async-workflows and http://docs.scala-lang.org/sips/pending/futures-promises.html . If Scala doesn't generate continuations aka green thread aka coroutines aka lwp .... I feel even less inclined to use it. I still think your *tone* is biased. – Adam Gent Feb 10 '13 at 00:23
  • @Adam Gent, Scala has a compiler plugin for continuations, which was not created for actors. In fact I am not even sure actors implementation (except akka.dataflow) makes use of that. If you still feel Scala compiler does some special things for actors, feel free to post a question at Scala mailing list. :) – missingfaktor Feb 10 '13 at 05:42
  • It's likely that you find my tone biased because you have decided to find a bias in it. :) The way I see it, what I have written here is a fairly objective comparison. – missingfaktor Feb 10 '13 at 05:43
10
  • 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.
cat
  • 734
  • 1
  • 7
  • 15
Ayush Goyal
  • 1,175
  • 9
  • 19
  • 5
    "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 05:05
  • 4
    "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 05:06
  • @missingfaktor: "It is way larger than Scala". How big are the grammars? – J D Nov 04 '13 at 20:00
  • 1
    I don't know if things have changed. Scala in IntelliJ rocks, with the plugin still open source. – Colliot Oct 11 '15 at 11:15
2

this is also a good article on the topic: comparing-scala-to-fsharp

as always, best way is to try for yourself!

//dotnet fsi --> starts F# interactive
//or open vscode and a .fsx file, install ionide, and start typing
#r "nuget: FSharp.Data" //will download your package
open FSharp.Data

//and you are good to use it
let add x y = 
   x + y

let r = add 1 2

type MyJson = JsonProvider<"""{ "test" : "me" }""">

let sample = MyJson.GetSample()

let me = sample.Test // string! typed, and is "me"

The very big difference to understand when checking functional languages is understanding language families and history, and know why ML language was invented and why Milner won an ACM touring award for it.

https://courses.cs.washington.edu/courses/cse341/04wi/lectures/02-ml-intro.html

The Why is the ML type system. both F# and Scala are statically (strongly) typed languages, but the strongest differences in my view are:

  • Scala has no ML type inference, and never will, and has very sad curly braces like C languages used just for scoping.
  • F# doesnt have higher order kinds (scala/haskell pp brag a lot a about it) also for a language design choice, the F# lang directive thought wasn't really needed in 99% of cases of real day to day programming and would confuse people (which indeed it does most of times)
  • F# uses curly braces for CE (Computation expressions) giving curly braces a total new meaning and dignity, for building monadic operations in the best expressive way ever. (see task, async, query, etc..)

Why is scala more popular?

A note on package management:

  • package management in JVM(maven) and nodejs(npm) is more complicated...
  • package management in NET works like a charm and is amazing, plus nuget is part of the dotnet tooling, not an "external thing" anymore, so dependencies are part of your .fsproj or a line in your script .fsx amazing.

ML was the first lisp-like statically typed programming language, and OCAML also supported object orientation and imperative construct, giving the most pragmatic approach to functional programming languages.

This lets you write "like python or javascript" and have strong typing like any strongly typed language.

Pros of F#:

  • it's a NET6 language runs everywhere part of the NET6 platform
  • has scripting and a repl and can be used like python/nodejs/bash
  • has type providers and the |> pipe operator, making it awesome to work with collections and data
  • has computation expressions, a very beautiful and simple way to write custom "monadic operations" in F# (not an expert here)
  • F#6 supports natively Task
  • runs on aspnetcore easilly with beautiful libraries such as Giraffe/Saturn/Falco
  • looks much closer to javascript and is much more readeable than scala
  • transpiles to javascript with Fable compiler
  • is based on many years of academic research and 25+ years of OCAML as is an ocaml implementation for .NET, making it one of the best functional languages available today
  • doesnt (yet?) run on the JVM, but is both a .NET language and a node.js language
  • has automatic type generalization and everything is curriable
  • is supported on very good IDEs: VsCode, Rider, VisualStudio
  • is opensource since long time
  • influences many languages (like C# and Typescript)
  • F# Synthax is more accessible and better as an entry level language too (~python) for people which never started programming

Cons of F#

  • doesnt have curly braces for scoping (but has for CEs, no worries!)
  • doesnt have Higher order Kinds... Oh No! big drama moment? (btw has generic interfces..)
jkone27
  • 39
  • 3
  • 6
    If the accepted answer reads as a little biased towards Scala, this is just blatantly a one-sided spiel about F# and fails to make a clear comparison. Note that the accepted answer was last updated over 8 years ago; much has changed in F# (can't speak to Scala) so an updated answer would be nice, but I don't think does a very good job of answering this question. – VisualMelon Dec 24 '21 at 16:15
  • yes i admit this is strongly biased in F# favor, but the bias is explained in the following points, so i see it as a "legit bias" :) or as a "strong opinion" , but i inderstand your point @VisualMelon – jkone27 Dec 26 '21 at 12:54
  • This answer gave too much emphasis on curly braces! – lprakashv Jan 03 '22 at 08:10
0

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

Joonas Pulakka
  • 23,534
  • 9
  • 64
  • 93
  • That's no longer true. F# has matured into a commercial product and it is no longer subject to MSR-SSLA licence (which means that you can use it for any purpose if you buy Visual Studio 2010). – Wizard79 Oct 13 '10 at 10:09
  • Ok, I stand corrected (F#'s Wikipedia entry is not up to date). So F# is a commercial product while Scala is free software. – Joonas Pulakka Oct 13 '10 at 10:24
  • @Joonas - Why don't you edit your answer? As it is now, we can't upvote. –  Oct 13 '10 at 12:35
  • Edited - although I would be interested in more precise license definitions; can't find such at fsharp.net. – Joonas Pulakka Oct 13 '10 at 13:26
  • 5
    Actually, F# is now open source and Scala is now a commercial product of Martin Odersky's company Scala Solutions. – J D Dec 27 '10 at 13:59
  • 4
    @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
  • 3
    @Joonas: Exactly, the same is true of F#. – J D Dec 27 '10 at 15:51
  • 6
    @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. – J D Jan 14 '12 at 22:05
  • 1
    I know your answer is old but today it is also wrong. F# is MIT licensed. – Alternatex May 27 '21 at 14:40