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?
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. :-)
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.
The Why is the ML type system. both F# and Scala are statically (strongly) typed languages, but the strongest differences in my view are:
Why is scala more popular?
A note on package management:
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#:
Cons of F#
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).
