Taking OCaml and Eio for a spin
19 points by winter
19 points by winter
OCaml sits in a great space where it can easily become the "Functional Go" but the tooling and ecosystem has just been too bad for me to seriously use it. Reading this post made me really nostalgic and want to use it again! Then I remembered that every time I want to use it in anger it feels like the tooling fights me. I know the community is working on making it more approachable and improve the tooling but it feels like the perpetual "year of Linux on desktop" meme at this point.
About fixing errors in bulk: I suggest using ocaml-lsp, which uses merlin. Recently typing recovery from Merlin has been upstreamed to the compiler, so the next version should be able to report more errors even without Merlin: https://github.com/ocaml/ocaml/pull/14241
There are no plans to enable the typing recovery mode in the compiler itself right now. The mode is mostly here to make merlin maintenance easier, and possibly opening the room for other developer tools to use it. There is already too much impedance mismatch between the information that the compiler report (or could report) in error messages and the compiler user interface, I would rather not dump even more information in the user terminal without a clear way for users to read it. Thus currently, my focus is rather on providing information in a more structured way to developer tools.
Overall, I am bit surprised by the report that the feedback loop from the compiler is too slow. Recompiling a file and going to the next error should take less than 200ms with a half-decent editor setup even without merlin or the OCaml language server.
Key here is an efficient editor setup that allows you to build with a single key combination, see the error and jump to the error location (or even better integrate the LSP for near instant feedback). I can see how the feedback loop could be considered slow if they haven't yet configured their editor correctly: exiting the editor, running the build command, then manually going to the error line would take a couple of seconds at least. I wish they would've reached out on discuss.ocaml.org about what exactly is slow, I'm sure someone would've been able to help improve their editor setup.
Looking at https://ocaml.org/docs/set-up-editor it only discusses how to setup an LSP , and it assumes the user would already know how to setup the basics, since that is not really that different compared to other languages. When I find some time I'll try to propose a section about efficiently using the built-in features of editors (e.g. the quickfix feature of Vim, etc.), before getting to more complicated setups that require installing plugins.