If you're writing anything for the browser, then I'll solidly recommend Reason. It works out of the box and ReasonReact is much more ergonomic compared to vanilla React + ImmutableJS + Redux + TypeScript combo. And there is a growing community around that use case in the Reason world.

If you want to write a command-line application, you can choose either OCaml or Reason, depending on your taste of syntax - both compile to native statically linked binaries. If you're doing anything related to compilers, OCaml is particularly suited for that, and you'll be in very good hands with Menhir (see: https://pl-rants.net/posts/case-for-new-lang/). Another systems software written in OCaml is unison (https://github.com/bcpierce00/unison), which is a file synchronization tool with a clear specification.

But if you want to write database backed web application servers in OCaml, with sessions, background jobs, admin interfaces, ORMs, database migrations and all that jazz, then you might want to give F# a go, or Haskell which has a better story around it. I do have a tiny Node server written in Reason that I use as an API endpoint but if I were to build a full-fledged system, there is nothing yet in the OCaml world like Rails or Django.

I used Unison for a decade, almost everyday, and it never failed. I never experienced this level of reliability with any other software. Perhaps all the credit goes to the programmer (Benjamin Pierce), not the language, but Unison certainly piqued my interest in Ocaml.

Thanks for the feedback. At this stage the goal is purely to dabble in FP with "Advent of Code" style mini-programs, and basically opening my developer chakras.

An added benefit would be to use this new language at work, which means that the size of the ecosystem (3rd-party modules, frameworks, etc.) can be a factor - one in which I guess OCaml is behind F# and Reason?

Note that OCaml and Reason are the same language with a different syntax. So when you're learning one, you're learning the other. There are some ecosystem differences because you can target native compilation, or JavaScript compilation. But otherwise the concepts carry over.

i personally highly recommend f#. it is one of the most practically designed langauges but still does functional and oop programming fantastically. some functional programming nerds complain it doesn’t have features like ocaml or sml’s modules or typeclasses like haskell, but it has other things that those languages don’t have. to my knowledge, it has feature parity with c# regarding oop with the exception of maybe a feature or two that doesn’t seem to affect things (i don’t know c#). meanwhile, it does functional programming very well.

it has nice error messages and clean syntax. it is easily installable on any platform. i took dan grossman’s programming language course on coursera. the first part of the course uses sml, and i simultaneously used sml, f#, racket, and scala to do the homework in. f# had the shortest solutions by far if counting lines of code.

a unique feature that i really like is its active patterns. f# already has amazing pattern matching, but you can define your own pattern matching with active patterns very easily. it is sort of close to defining your own pattern matching dsl.

in my opinion, it is criminally underused and under marketed by microsoft. in a world where python is taking over, f# is very refreshing.

Thanks, I'll have a look at F# syntax to see if it resonates. Is there a tutorial or (text)book you would recommend to get started?

> in a world where python is taking over, f# is very refreshing.

Can you elaborate? I happen to like Python but I'm always open for refreshments :D

the oft recommended f# for fun and profit is good as a reference, but i personally haven't found it good as a tutorial. the explanations are often not expedient and show (too) many ways of doing things to get to the point. i go there when i have something very specific in mind. i often find the official microsoft f# documentation to be quite good and my go to reference.

as for books, there are a lot. none of them really fully resonate with me, although they are usually pretty good, but the book functional programming using f# by hansen and rischel is fairly nice. it is more academic in tone, although it was written a while ago against an older version of f#, so there may be some slightly out of date or style code. the book expert f# is by the language designer, and it shows some nice advanced stuff in a clear way.

i also recommend going through the little mler by translating the sml code in the book to f#. it will get you used to using types and pattern matching the way they are done in ml dialects. you will be able to do everything up until they cover the module system.

i have some very simple code here: https://github.com/nikofeyn/ray-tracing-with-fsharp/tree/mas...

it isn't documented or to my usual style, as it is an incomplete project. i was going through the book ray tracing in one weekend by peter shirley and didn't finish. and this code was actually "ported" from racket code that i had originally started the book with. so it went from c++ -> racket -> f#. however, it shows some representative f# syntax for some numerical stuff. i have some more f# projects that show more type-based programming and pattern matching styles, but they are in private repositories.

i personally just do not like python. it feels very sloppily designed to me, and i prefer scheme-based languages like racket and ml-based languages like f#. i have only worked in python when work has compelled me to, and i hated every instance of it. a large majority of it is that python is just difficult to reason about and is sloppy. that and the ecosystem, while vast, is very sloppy. i have encountered countless dependency issues and version headaches with python. it just isn't fun. all the work to get something working in python is just not worth it and unless you are reliant on some particular library, i personally don't see a reason to use it.

meanwhile, racket and f# remain as easy to develop code as python, except that the code developed works and works well. they are just extremely nice languages to use. they are the only languages i have used where it doesn't seem they are fighting me.

if you use python's async code, check out f#'s async expressions. they are extremely easy to use.

i highly recommend dan grossman's programming languages course on coursera. the first module uses sml (you can basically directly port all the code and your own code to f# for fun and very easily). the second module uses racket. and the third module uses ruby. i recommend it for any programmer and especially for some not used to the functional style.