The author wants the line repeated and the error underlined with carets.
For my part, I use Go and I’m pretty happy with the short error messages because the LSP does error highlighting. It would be sort of weird for me to be surprised by a compilation error.
Go’s short but high quality error messages make understanding what’s wrong a quick low effort glance. Extra lines would make it less convenient for me.
However, I get why the longer error messages are needed in Rust. I’m much more likely to be puzzled by a Rust compiler error, and when I am I need all the help I can get.
I think the type of error messages needed really depends on how complex the compiler is to understand.
Typescript supports a pretty multi line output format, and claims that it’s enabled by default. Perhaps the author wasn’t using a TTY for stdout? Using a non-TTY switches to single-like machine readable output.
I tend to think that optimizing for error messages gets stuck in a local optimum. When I was coding in Kotlin, I never have to look at the compilers stderr, because errors are always immediately shown as I type. Most of the time I don’t need error message at all, just seeing the error appear immediately when erroneous code is entered. Time to show error > precise span with the error in the editor > error message,
The feature of syntax_suggest (formerly dead_end) is integrated into Ruby. This helps you find the position of errors such as missing or superfluous ends, to get you back on your way faster, such as in the following example:
Unmatched `end', missing keyword (`do', `def`, `if`, etc.) ?
1 class Dog
> 2 defbark
> 3 end
4 end
And:
ErrorHighlight
Now it points at the relevant argument(s) for TypeError and ArgumentError
test.rb:2:in `+': nil can't be coerced into Integer (TypeError)
sum = ary[0] + ary[1]
^^^^^^
That tells me the error is at line 4 column 17. What am I missing?
The author wants the line repeated and the error underlined with carets.
For my part, I use Go and I’m pretty happy with the short error messages because the LSP does error highlighting. It would be sort of weird for me to be surprised by a compilation error.
Go’s short but high quality error messages make understanding what’s wrong a quick low effort glance. Extra lines would make it less convenient for me.
However, I get why the longer error messages are needed in Rust. I’m much more likely to be puzzled by a Rust compiler error, and when I am I need all the help I can get.
I think the type of error messages needed really depends on how complex the compiler is to understand.
Typescript supports a pretty multi line output format, and claims that it’s enabled by default. Perhaps the author wasn’t using a TTY for stdout? Using a non-TTY switches to single-like machine readable output.
https://www.typescriptlang.org/tsconfig/#pretty
I tend to think that optimizing for error messages gets stuck in a local optimum. When I was coding in Kotlin, I never have to look at the compilers stderr, because errors are always immediately shown as I type. Most of the time I don’t need error message at all, just seeing the error appear immediately when erroneous code is entered. Time to show error > precise span with the error in the editor > error message,
It’s not clear to me why making error messages better would preclude improving editor integration. We can have both.
The recent versions of Ruby have pretty nice error messages, too. Under Other Notable New Features:
Ruby 3.2.0 Released
And: