←back to thread

Learn OCaml

(ocaml-sf.org)
203 points smartmic | 3 comments | 27 Jun 25 20:36 UTC | HN request time: 0.428s | source
Show context
aryonoco ◴[28 Jun 25 06:05 UTC] No.44402589[source]▶
OCaml is nice. I like it a lot.

But arguably F# (whose original name was OCaml.NET) is underrated. It improves on OCaml in a number of areas (better pattern matching, computation expressions, namespace support) but more importantly, F# solves OCaml’s biggest problems: lack of decent libraries and subpar tooling.

With F# you get instant access to thousands of high quality NuGet packages which includes everything from fast web servers to highly performant json deserialisation, and you can use some of the best IDEs, tooling and debugger around (JetBrains Rider is outstanding IMO).

F# suffers from the Microsoft association unfortunately, even though Microsoft barely cares about it and provides minimal support for it, most good things about F# are developed and maintained by the community. But the perception exists, and many think it’s still Windows only

I’ve recently been doing a lot of F# development, I do my work on a Mac, using Rider and OCI dev containers, and the code is deployed on Kubernetes, and honestly I don’t remember the last time I enjoyed a programming language and development tooling so much.

replies(1): >>44403211 #
1. zeroc8 ◴[28 Jun 25 08:48 UTC] No.44403211[source]▶
My dayjob involves a lot of Java, but the problem I'm working on seems to be a really good fit for a functional language. I've played around with Erlang, Elixir, Clojure and F#. The problem is that I'm always worried about getting stuck somewhere along the process and then end up regretting the decision to not use something more mainstream.

But F# seems to be a real beauty.

replies(2): >>44405295 #>>44417986 #
2. yawaramin ◴[28 Jun 25 15:18 UTC] No.44405295[source]▶
If your day job is Java, learn Scala 3. It will be a mind-expanding experience.
3. throw234234234 ◴[30 Jun 25 00:36 UTC] No.44417986[source]▶
Generally you won't get stuck with F#, unless you would of got stuck with C# also. The escape hatch is there, with its pros/cons. The pro is mentioned - the con being that this is where F# gets im-pure and someone with experience would immediately have patterns/team standards to deal with the boundary/usage. C# libraries generally don't have this problem (e.g. Collections, Connection Libs/SDK's, etc) since you invoke them like any other function/object - C# frameworks which invoke your code (e.g. ASP NET Core) you typically need standard code patterns to allow most of your F# code to remain pure/simple.

In general though I prefer the .NET runtime than the JVM in its current state - you can go a little bit lower level when required in hot code without going unsafe (value types, spans, etc).