That was done by @compiler-errors, as part of an improvement to make some of the suggestions I introduced easier to read.

I was a big advocate of adding error codes. I don't remember specifically the timeline, but we had so much stuff to do for 1.0, it doesn't surprise me that it got pushed back a bit.

At the time, I was thinking about the big old chunky Visual Basic manuals I used to own, and how useful those were.

EDIT: okay, so I'm doing some digging: error codes were added before 1.0... https://github.com/rust-lang/rust/commit/0e80dbe59ea986ea53c...

> This implements the minimal scaffolding that allows mapping diagnostic messages to alpha-numeric codes, which could improve the searchability of errors. In addition, there's a new compiler option, `--explain {code}` which takes an error code and prints out a somewhat detailed explanation of the error.

committed on Jul 10, 2014

I think I've figured out what happened here: the particular error that was chosen didn't have a code until 1.2. The example from this commit does show a code on Rust 1.0.0: https://godbolt.org/z/14hcb3ETG

I agree - as somebody who’s learning Rust, I like how the compiler allows me to quickly go from making a mistake to understanding why and being able to avoid it in the future, which makes the experience less frustrating. I like how Rust is somehow complicated yet easy to learn (if that makes sense).

Wow, you're right. Apparently this was Rust in 2010-06-23:

    io fn starve_main(chan[int] alive) {
      log "signalling main";
      alive <| 1;
      log "starving main";
      let int i = 0;
      while (true) {
        i += 1;
      }
    }

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]

> 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.

This is something that I never get tired to hear. I'm really glad that you've found them helpful.

I don't remember where, but I once heard someone talk about "error-message-driven-development" in Rust -- that is, using the error messages provided by rustc to guide you in your development process by way of fixing bugs in naively-written code. I even did a talk to several dozen engineers in my previous group about how fantastic it is: a newbie can write what they think is reasonable code, the compiler will reject the program but provide useful information, and the user can iteratively apply changes to the point where you can almost get things exactly as you want it. A lot of people who knew nothing about Rust were super impressed by the messages reported.

Many thanks to you and others that have toiled at this incredible UX!

When maintaining a project, one gets exposed to the worst parts of it at an elevated rate. This makes maintainers be more critical than most, as we have an skewed view of the projects faults. So I can absolutely understand when someone claims that rustc has bad errors. I've seen them. But for most people most of the time the output is actually quite good. That shouldn't stop us from being better. I'm thankful for the OP because it does show that we do improve over time.

I keep saying that the most effective thing we can do to help someone learning the language is to tell them to try in 6 months (as we expect it'll be better then).

When you have complex types with complex bounds, the compiler rarely can link these types/bounds and you end up with cryptic error messages. You know there is a missing bound somewhere but it could be anything until you read and fully understand the type structure that the author of the library has put. Sometimes there is a trait to import but the LSP sometimes catches it and in some odd cases does not. Shit really hits the fan if you are using proc-macros.

Is it possible to get rid of these help texts or make the error messages more concise and to the point?