Thanks for poking at this issue @sid Apologies for the wall of text to follow
Disagree on the Haskell somewhat, it is eminently practical, tracking side effects is a fantastic feature. Knowing there is an STM or IO in the type signature reveals important detail. Monad Transformers (or Effects) are as much familiarity as complication. Getting to the familiarity point is tricky best done with supervision from an experienced mentor, without well I think that is where Haskell is really hard and makes for horror stories about people bouncing off the language in frustration
Strongly agree with the tooling blessed path:
- lsp with VSCode (or other editor)
The documentation piece still needs work and I wouldn’t point to
docs.ocaml.pro as a hoogle equivalent.
Type directed search is still pretty rough as a user, in Haskell I would have a local hoogle based off my
current project installed and search libraries / my code for types or functions. That workflow in OCaml is
usually via google or grep and not at all seamless.
utop is weird as you said it’s more limited than
cabal repl, I only use it for very
specific small tests in my day to day work. eg today messing with Hash algorithms
Mirage_crypto.Hash.SHA256.(hmac ~key body)
GHC/Haskell build times are indeed pretty nasty, better now with newer cabal and dependency caching.
I feel that Haskell programmers ask the compiler to do a lot more work than is typical in OCaml, for example Template Haskell doing code generation, deriving typeclasses, along with my favourites of Functional Depedency solving / Type Families. Even with that an equivalent sized Haskell project is slower than an OCaml project.
The issue with OCaml tooling is mainly down to polish and documentation (many of the pieces are
there or being actively worked on just not as well documented as Rust), it has come a huge way over
the last few years (do not want to deal with Oasis again). Not being a Rust programmer, could you
talk more about which things
cargo does that are missing in OCaml?