←back to thread

135 points ingve | 5 comments | | HN request time: 0.34s | source
1. kaycebasques ◴[] No.44007633[source]
Effective error messages are one of my platonic ideals about how documentation is supposed to work. The docs shouldn't be shoved off to the side. They should appear just-in-time, when you need them. If you can fix the error within the product (e.g. when Rust tells you exactly how to fix the typo), just do it there. Otherwise link off to the full docs when it's too much content.

The general platonic ideal is "have the product automatically fix the issue" => "provide short documentation within the product if the problem can be explained with just a paragraph or two of content" => "link to a targeted doc that deals with this exact problem if it takes more than a few paragraphs to explain"

A lot of time, my work as a technical writer is advocating to update the product (or updating the product myself) to do the first two steps, rather than just jumping immediately to the last step. Startup people often refer to this as "the perfect product requires 0 documentation." When teams always resort to fixing product issues with docs, your docs start to get huge and complicated. We technical writers often refer to this as "putting docs lipstick on the product pig."

replies(2): >>44007926 #>>44009153 #
2. tialaramex ◴[] No.44007926[source]
Yes, the article goes to some length to mention this but it's worth re-stating, this is all real work, people spent a bunch of effort improving Rust's diagnostics, it's not the case that somehow the errors magically get better as the compiler's optimisations improve or something, if you did X and that can't work but the compiler said how about Y, that probably means a person like you had a similar situation and they put work into modifying the diagnostics when you can't do X so that it realises it should suggest Y.

My tiny contribution is that when you write say '$' (the dollar symbol as a Unicode char) in a context where you needed a single byte, now rustc will suggest prefixing with a b to make b'$' (the ASCII code of a dollar as a single byte) rather than just telling you that's the wrong type, and yet if you write '€' (the Euro symbol as a Unicode char) it will not suggest b'€' because that's not a thing, the Euro isn't a single byte in ASCII

[Yes in some modern 8-bit encodings € exists but those encodings aren't used in Rust, which favours UTF-8, so b'€' wouldn't make sense, in UTF-8 this symbol is 3 bytes]

3. epage ◴[] No.44009153[source]
> The general platonic ideal is "have the product automatically fix the issue"

`cargo fix` will apply programmatic suggestions from rustc. We are very conservative of which suggestions we apply but will expand it when we add an interactive mode.

replies(1): >>44009324 #
4. estebank ◴[] No.44009324[source]
This is an approach that I really like because of some not necessarily obvious properties: the behavior of the code as written is easily predictable, while still getting the benefits of a compiler's help. The suggestions can be more aggressive than automatic changes, because a human is in the loop and they can apply judgement of whether a certain strategy is beneficial or not.
replies(1): >>44009443 #
5. epage ◴[] No.44009443{3}[source]
We can also offer more precise choices: say you have an ambiguous `Deref`, instead of saying `T` in the turbofish (for brevity), we could let the user select from the different available `Deref` impls what should be inserted.