Taking OCaml and Eio for a Spin

mattjhall.co.uk

61 points·mattjhall··6 comments

> The compiler bothers me more. When it encounters an error it seems to give up on the rest of the file. This makes the iteration loop quite slow - write code, get an error, fix the error, rebuild. There's very little chance to fix errors in bulk, especially if you're focussed on one module.

Are there languages where this actually works, in actual practice? No compiler I have ever used in anger was reliable enough in its error recovery, no matter how hard it tried. So when working on the command line, I always scroll up to the first error and ignore the following ones. Any work the compiler puts into showing me more than the first error is wasted, from my point of view. And it wastes my time, so I view this as a net negative. Again, not the lofty idea, but the practical implementation in compilers I've used. (IDEs can be better. IntelliJ is sometimes even actually good. Not always.)

The author mentions Rust, is the Rust compiler really that good at reliably guessing the correct way to recover? Even in the face of, say, complex type errors?

if nothing else, you could guess that a compilation error within a function body would still let other functions be compiled, and proceed on that basis.

Depending on the error, the grammar, and the parser, it may not be possible to close the function body. Most compilation units are file-based for this reason.

It doesn't hurt here that the OCaml compiler is very fast, which makes for quick feedback loops when dealing with errors.

Biome, the JS formatter and linter in Rust, is quite robust to this, as it works on ASTs and can deal with broken trees.

I never experienced this as a problem while working with OCaml. I wonder if the author is aware that the compiler can be ran in “watch” mode where the project is immediately rebuilt on file save.

Reply on news.ycombinator.com