NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Taking OCaml and Eio for a Spin (mattjhall.co.uk)
derdi 3 hours ago [-]
> 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?

satvikpendem 3 minutes ago [-]
Biome, the JS formatter and linter in Rust, is quite robust to this, as it works on ASTs and can deal with broken trees.
zem 3 hours ago [-]
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.
jallmann 2 hours ago [-]
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.
tlavoie 1 hours ago [-]
It doesn't hurt here that the OCaml compiler is very fast, which makes for quick feedback loops when dealing with errors.
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 00:54:32 GMT+0000 (Coordinated Universal Time) with Vercel.