OCaml -> Scala vs F#

Hypothetically, if you were forced to use a non-ocaml language, and the choice of platform was irrelevant (i.e. please no .Net vs JVM arguments), would you go with F# or Scala ?

Context: I’m really curious about the merits of these two OCaml alternatives, from the perspective of language features, compile time, and IDE support.

Thanks!

1 Like

For my part, I’ve not written anything in either of those languages, but I’ve read a fair amount of the Scala documentation trying to learn how some of its more peculiar features work, and I’m pretty sure that, if I were made to choose between F# and Scala, I’d pick Scala. Mainly because F# would annoy the hell out of me, on account of it being more or less, “OCaml with all the good bits removed.” Whereas, pretty much everything I like about OCaml has a mostly reasonable alternative in Scala. And Scala has ad hoc polymorphism too.

2 Likes

I’ve used scala extensively in the last 7 years at work, but I have never used F#, the only knowledge of F# is from reading online. The experience of Scala is pretty enjoyable to me.

In a short sentence, scala has two advantages. (1) it basically has almost everything Haskell has: type class, for example. (2) Access to the entire JVM ecosystem, scala can call Java libraries pretty effortlessly.

The disadvantage: (1) compiling is much much slower… (2) People used to say scala devs have to deal with Java style of Scala from new coworkers, but it seems all Java style of Scala projects either move to Kotlin or moved back to Java now. The remaining scala project is pretty much functional style.

From everything I’ve heard, F# unfortunately still just doesn’t have that great of an IDE experience. The cross-platform open source stuff seems to be buggy and slow. Also F# needs the user to manually sort their project files in compilation order. The order isn’t inferred like it is in OCaml.

As much as I like OCaml and some of that fondness carries over to F#, in reality these issues would drive me towards Scala, which has doesn’t have these issues and also has some banger libraries for very practical, performance-oriented programming, like ZIO.

2 Likes

I’d go for F#
compilation speed and tooling (rider/vs) are much better than scala’s
the language isn’t as flexible/featureful, but has many good practical features (e.g. type providers)
it’s OCaml-ish and much of your OCaml knowledge translates 1:1, scala on the other hand would take a bit more time to get up to speed with.

1 Like

I used F# 2-3 years ago for 2 smartphone apps (Fabolous & Xamarin) and a cross plattform GUI (Avalonia & Avalonia.FuncUI). All on Windows using Visual Studio and Net Core 5.0 with F# 5. As I did not succeed using the F# package manager (Pack?) with Xamarin I used VS to manage the Nuget packages for the Xamarin/Android part. After an update had to delete all Nuget Caches on the whole system to be able to build the project again. The language itself is fine and IDE support was, well usable (not comparable to C#).
My only Scala (2) I did was dabbling a bit in the Flix (another JVM language) compiler. If somebody told me, that that had been modern. Java (last version I have used had been 1.4?, the last Version that worked on Irix) I would have believed that. It feels like the worst features of Haskell, C++ (the “let’s include the feature, no matter if it fits with the rest of the language”) and Java in a single language.

Compile time of .Net and JVM stuff is too long. But with .Net you can at least cross compile to a binary containg the runtime for each of the supported plattforms.

So F#. On the JVM I’d use Flix (which isn’t usable at the moment), Clojure or Kotlin before considering Scala.

Actually I’m using Haskell as the OCaml alternative.

But because of the way MS treats the .Net OSS community, I stay clear of it.

1 Like

I’ve used both F# and Scala professionally. Scala for a much shorter time.

Under most circumstances you will not actually be making a choice between them, because F# is .NET and Scala is JVM. You, or the people who made the choice for you, likely picked the platform first.

Hypothetically, if you ignore the platform, which most don’t, then I’d say whether you like F# or Scala more depends on whether you prefer a relatively simple minimalistic language or a language with lots of features. If you are the person who writes “X language feature or GTFO”, you will likely hate F# and love Scala. If you like concise straightforward functional code and like to get things done, you might prefer F# rather than Scala.

IDE experience with either wasn’t perfect for me. My Scala (2.13) experience with JetBrains tooling was absolutely horrible (the IDE simply didn’t agree with the compiler on our 6 figure LOC codebase) so I switched to using VS Code with Metals, which seemed to better (but not 100%) agree with the actual compiler and gave an Ok experience. I’ve programmed in F# with Emacs (which I usually prefer), VS Code, JetBrains, and Visual Studio. None of these give perfect experience, but have been Ok. Programming Scala without an IDE is not something I’d recommend (various features of Scala, like implicits, zero-argument functions, and by-name parameters, pretty much require you to have an IDE, because code (control flow) is not understandable locally), but I have found programming in F# (and Standard ML and OCaml (both of which I’ve used professionally)) productive even without an IDE (just syntax highlighting and grep).

I don’t understand the problem some people have with ordering files in F#. If you don’t mind lexically ordering your definitions in OCaml, then ordering files in F# shouldn’t be a problem to you and you might appreciate that it can make the code simpler and make the code easier to navigate and understand. In a project of any size the time you spend ordering files manually is absolutely insignificant. By contrast, in the Scala project I experienced professionally, there were internal “libraries” that had cyclic dependencies with application specific code and some people preferred top-down and others bottom-up ordering for definitions and some probably didn’t even think about the ordering.

If I were starting a project on JVM, I’d likely seriously consider Kotlin (which I have also used professionally) before Scala. In particular, if I knew that co-workers on the project would not be hard-core FPers, I’d likely recommend Kotlin rather than Scala. On .NET C# (which I’ve also used professionally) is orders of magnitude more popular than F#, but I definitely prefer F# as a language.

2 Likes

I’ve been a fan of F# for many, many years, and I would normally recommend it for it’s simple “functions + immutable data” philosophy over any language for “type-level astronauts” like Scala or Haskell, however I can’t do so anymore:

  1. F# has an strong inherent tension between its FP-first and OO-first language features, and while the ecosystem wants to promote the first, the second are actually more polished and full-featured, and a better match for the platform.
  2. C# is driving a lot of churn to the idioms and features of .NET, and while F# is trying to catch up, it’s not doing so fast enough, leading to many, many edge cases, missing features and increasingly clunky C# interop.
  3. F# development as a whole seems to be stalling, with few features beyond (attempts at) interop being added. Suggestions to solve many pain points of the language become “approved in principle” but consensus on how isn’t reached, or they make it to an RFC that no one actually implements.
  4. The toolchain (compiler and MSBuild) is really slow, and the open source editor tooling (VS Code extension, formatter, language service, etc.) is really fragile, breaking every other release (or .NET release) and hanging or misbehaving every few minutes.

Since most other FP languages are either for “type-level astronauts” or dynamically typed, and I’m seeing that memory access patterns are the new bottleneck for performant code, I admit I’m drifting away from FP entirely. When OCaml isn’t a good fit, I now just consider C#, Go or Rust (too trait heavy for my taste though) for my own projects. I’m not a fan of the JVM, but I wouldn’t mind using Clojure again when performance didn’t matter.

2 Likes