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
Yes, Rust has some inherently tricky parts that require programmers to really understand them before they can write it effectively. However, it goes out of its way to teach those concepts more than I realized it was possible for a compiler to do.
Regardless, very cool!
io fn starve_main(chan[int] alive) {
log "signalling main";
alive <| 1;
log "starving main";
let int i = 0;
while (true) {
i += 1;
}
}`io fn`, there were three effects: io, state, and unsafe. There was also pure, for functions with no effect.
chan for channels. <| was a "semi-synchronous message send," it blocked if the queue was full.
square brackets for generics
int was two's compliment signed integer with machine dependent size
log for printing to the screen
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."
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]
`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.
Sometimes I want an excuse to write some Rust. I think I'll make one in my upcoming web app, since it already uses web workers. I guess the side effect is that wasm (and therefore Rust) will become a first class citizen in my app? Neat.
Many thanks to you and others that have toiled at this incredible UX!
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).
The newest errors tend to be noisy for my taste, and I have to tune out the advice to see the error.
swsieber•13h ago
estebank•10h ago