Language ergonomics is a really underrated feature. I remember having to link system libraries to follow an OCaml tutorial, which was extremely painful. Or running into issues installing Snap for Haskell where the package manager would basically go ¯\_(ツ)_/¯. While on the other hand Cargo has been a breeze to set up and work. Makes all the difference when your users aren't willing to dive into the source code to fix the issue or wait for a StackOverflow/GitHub Issue response.

I am sure this is why the majority of software in use today is written in programming languages with great ergonomics such as C/C++ or Java. Besides you can’t use cargo once you are not developing a green field project and multi-language ergonomics can totally suck.

Opam combined with Oasis (https://ocaml.org/learn/tutorials/setting_up_with_oasis.html) does pretty good job IMO.

My personal issue with OCaml eco-system is that for quality tooling Emacs feels like the only option.

I am using VSCode with vscode-reasonml extension and I thought it is pretty good. Am I missing something by not going with Emacs?

In all fairness I tried it few months ago. Auto-complete was hit and miss and sometimes got false negative errors. Glad to here it works now apparently! :D

The best way to setup OCaml (native) is to follow https://github.com/janestreet/install-ocaml. If you're following Real World OCaml, the stdlib they use is Jane Street's Core/Base, which is quite comprehensive compared to the one shipped with the language. Mixing and matching the book with the language's own stdlib can cause a lot of heartburn.

There is also a lot of work going on in making the OCaml native development experience easier. install-ocaml (link above) actually takes you through building and testing a project using Dune (formerly JBuilder) which is fast becoming the standard way to build OCaml projects.

If you are however interested in just the language, you can get wonderful ergonomics by using BuckleScript/ReasonML. You'll be running your code using Node, or in the browser, and you'll get access to the large and wild npm ecosystem. You'll lose out on the native OCaml ecosystem, but there are attempts to meld both together.

If none of this is your cup of tea, then you have a great alternative in F# - it is Microsoft's attempt at OCaml, and has a few great features that are not present in the original language. It comes with great Visual Studio IDE integration and sits in the .net ecosystem like Clojure or Scala does in the JVM ecosystem.

Or you can use Elm or PureScript which are statically typed functional programming languages that run on the browser, or Haskell, or even Idris.

These languages have great differences between them, but all of them are ultimately statically typed functional programming languages. Julia is not. Typed FP gives you ADT, immutability by default, functions as first-class constructs, and lets you model complex software as just pure transformations of data. These things are worth learning just for them, and once you understand the motivations behind them well enough, the occasional jank would be but minor annoyances.

I'll definitely be giving it a try again at some point in the future, or one of the alternatives. I learned a ton even just dipping my toe in the waters.

We don't know yet if the developers of Julia value backwards compatibility -- they haven't reached 1.0 yet. So, I find that a rather strange choice given the reason you put forward against ocaml.

That's funny because that's exactly how I felt about learning OCaml, except that I reverted to Python instead (and retrospectively wondered what the heck I was doing toying with such a mess.) You got to find a language you feel comfortable with and that gets stuff done without fussing around with basic stuff like core libs and tutorials. It's a shame developers of the core language don't get it and sabotage the adoption just for lack of craftsmanship. I am sure OCaml would have been fantastic for my use case (context free parsing) but I just gave up and went back to something that just plain worked.

It has improved a lot over the last years. And python falls flat in other areas once you’ve hit a critical mass of code.