A lot of the error messages in Base are carefully worded to fit on a single line. This often comes at the cost of them being pretty inscrutable to new users. I'd like to propose a systematic effort to lengthen and clarify our error messages. There are many examples, but I was prompted to open this issue by this post on StackOverflow:
https://stackoverflow.com/questions/63188794/difference-between-fsstring-and-fstring
The question is not about inscrutable error messages, but the answer includes this error message:
ERROR: all-underscore identifier used as rvalue
I know what that means, but, man, that's not going to make sense to most people 馃槵. What's the best strategy for making all our error messages easier to understand for people who aren't deeply steeped in Julia development?
There are at least two things you can do in an error message: describe the problem and provide hints about how to fix it. The second is attractive but the first is much safer, and it's likely that only the first is always possible. So as a first pass I would focus on trying to come up with less jargon-heavy ways of saying the same thing.
I've long meant to do the same thing to the manual (which has some very newbie-friendly sections but some that are not), but that's a big task and it hasn't yet risen to the top for me.
For syntax errors, what about giving every error a unique type or a short unique string (e.g. "(all-underscore)"
) to its error message? I think the hints should be "rich" and the rich hints should only exist in the documentation.
I'm not happy with the hints of Rust's linter (clippy), but I think its ecosystem itself is great.
https://rust-lang.github.io/rust-clippy/master/index.html
Taking off the milestone.
Most helpful comment
There are at least two things you can do in an error message: describe the problem and provide hints about how to fix it. The second is attractive but the first is much safer, and it's likely that only the first is always possible. So as a first pass I would focus on trying to come up with less jargon-heavy ways of saying the same thing.
I've long meant to do the same thing to the manual (which has some very newbie-friendly sections but some that are not), but that's a big task and it hasn't yet risen to the top for me.