
Shape of errors to come - runesoerensen
https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html
======
cfallin
I really appreciate the user-friendliness of Rust's error messages -- I can't
remember seeing a compiler tell me "maybe try this instead?" before (perhaps
something from Clang, but never with the specificity of, e.g., a suggested
lifetime annotation). And from a parsing / compiler-hacking perspective, it
seems _really_ hard to get the heuristics good enough to produce the "right"
root cause. Kudos to the Rust team for this continued focus!

~~~
jerf
It's taken... I dunno, 50+ years?... but it's nice to see more and more code
being written that doesn't assume programmers are superhuman beings with an IQ
of 250 and infinite concentration and working memory. We need all the help we
can get, so that we can focus as much of our precious, limited cognitive
firepower on what really matters. When even John Carmack is talking about
getting all the help he can from his development environment [1], you really
ought to listen.

[1]: [http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html)

~~~
cmontella
> it's nice to see more and more code being written that doesn't assume
> programmers are superhuman beings

I would say that most compilers don't even assume the programmer is human. The
root cause of bad errors is that they emanate from the compiler, and are
reported from the perspective of the compiler. That's why you get errors like
"can't access method undefined of undefined", or the hell that is C++ template
errors. Sure, the errors make perfect logical sense from the perspective of a
compiler, but they make my human eyes bleed.

My favorite is a single missing semicolon that causes a cascade of unrelated
errors, none of which indicate there's a missing semicolon.

grammars, parsers, compilers, and languages as a whole should be designed for
humans _first_. Even if it makes the language implementation a little more
complex, human users will benefit greatly and thank you for it.

~~~
boznz
I think that is why ADA became popular for mission critical stuff as you can
inform the compiler a lot more about the constraints and so in effect make the
compiler more user friendly. (Disclaimer happy to be corrected as I have never
used ADA but I just finished listening to the podcast on embedded.com and
thought it relevant)

~~~
msbarnett
The biggest correction I have is that it's not an acronym -- Ada, not ADA.

~~~
eatbitseveryday
"ADA" as an acronym is more easily know as "Assistant District Attorney".

~~~
nommm-nommm
I read ADA first as Americans with Disabilities Act
([https://www.ada.gov](https://www.ada.gov)).

In all seriousness,

Ada the programming language is named after a person - the English
mathematician Ada, Countess of Lovelace known as "the first computer
programmer" (
[https://en.m.wikipedia.org/wiki/Ada_Lovelace](https://en.m.wikipedia.org/wiki/Ada_Lovelace))

------
justinsaccount
In my little rust experience the suggestions the error messages had, even in
the longer explanations, were useless. Mostly it came down to me trying to do
something that was simply not supported, but the compiler not knowing that and
leading me on a wild goose chase.

From what I remember, I was trying to use the iterator trait, but return
records that contained str pointers.. The goal being to parse a file and yield
pointers to the strings from each line to avoid allocating memory and copying
bytes around. Rust tries to tell you that you need lifetime specifiers, but if
you try adding those nothing compiles anyway because the iterator stuff
doesn't actually support that.

I eventually got it to work by returning copies of the strings.. maybe the
unsafe stuff would have done what I wanted, that's what rust-csv seems to do
at least.

I concluded that Rust is definitely not a language you can learn by chasing
down error messages and incrementally fixing things. If you don't 100%
understand the borrow and lifetime stuff, fixing one error is just going to
cause two new ones.

~~~
steveklabnik
Hm, iterators can definitely return pointers. Post on users.rust-lang.org or
drop by IRC sometime! We're happy to help.

~~~
justinsaccount
Oh? Maybe I was looking up the wrong thing. Now that I search again I think
this is what I was trying to do:

[http://stackoverflow.com/questions/30422177/lifetime-in-
iter...](http://stackoverflow.com/questions/30422177/lifetime-in-iterator-
impl)

though in my case I had a vec of &str or something like that.

What I do remember was the compiler sending me in circles. Honestly if it had
just said something like "Hey dummy, you can't do that, go read the chapters
on lifetimes again" I might have fixed it. But it kept telling me things like
"Just add a lifetime specifier on this line" and I would do that and then get
2 more error messages. I think the errors sent me down the path of trying to
do what the SO post mentions, which is

    
    
      fn next<'a>(&'a mut self) -> Option<Vec<&'a T>>
    
    

instead of putting the lifetime on the impl block, which probably never even
occurred to me was something you could do.

~~~
steveklabnik
Ah ha, yes, this is more than just pointers. It's a "streaming" iterator as
opposed to just an iterator, and yeah, we need more types, IIRC, before that's
possible.

As I mentioned below, we love bugs about bad error messages, feel free to file
them!

~~~
ckarmann
Well, if you love this kind of bug reports, please take a look at the one I
filed a while ago :) [https://github.com/rust-
lang/rust/issues/11724](https://github.com/rust-lang/rust/issues/11724)

Thanks!

------
dllthomas
Please put file locations (as many as might be relevant) at the start of _a_
line in the standard format!

The other changes look valuable. Improving error reporting is great.

Edited to add emphasis: I really did mean _a_ line, not _every_ line.

~~~
pcwalton
Those file locations repeated every line accounted for a lot of the noise in
the previous format. I'm glad they're gone.

~~~
nhaehnle
Please, take those complaints from others seriously.

There are plenty of tools that help people (including myself) to deal with
compiler errors more easily, and they're not limited to emacs either.

For most purposes, having at least _one_ line in the standard
'filename:linenumber:[column:] {error,warning,...}:' format is sufficient for
compatibility. You have such a line already; just remove the '\-->', add the
'error:' or whatever back in, and you should be good to go without sacrificing
any of the (very welcome!) improvements from this change.

~~~
steveklabnik

      >  Please, take those complaints from others seriously.
    

We are absolutely taking it seriously. We do not want to regress on tooling
for this, and in fact, plan on making it _better_ not worse.

------
waynenilsen
I would love to see an option for showing the error order forward or backward.
My workflow is to start fixing compile time errors from the top of the `cargo`
output but scrolling to the top can be fairly annoying when there are a lot of
errors. Having the most relevant error at the bottom of the command line
(where it automatically scrolls) would be useful as an option IMO. This
probably causes some other unseen problems however

~~~
klodolph
I find it's much easier to use editor integration to do this, rather than
opening a separate terminal window to compile.

~~~
0xffff2
Do you use Windows? I haven't found an editor with decent Rust integration on
Windows yet.

~~~
pjmlp
Visual Studio Code.

Its Rust support is the only reason I care to use a web based editor as
desktop application.

------
gnuvince
Very good! I always liked the content of Rust's error messages as it clearly
explained the issue, but the _form_ of those error messages was a bit
problematic, they were very noisy and it wasn't easy to see the issue by
simply glancing, you had to scroll up, find the beginning of the error and
read carefully.

------
karysto
I always love it when we bring UX to the the tooling we use, and not just on
the end product in our users' hands. Everyone appreciates a delightful UX,
including software engineers. I've been eyeing Rust for a while now, this just
gives me another excuse to hack with it.

------
ColinDabritz
I love the clarity and readability of these errors. You can work on UX at
lower levels, and it looks like this. Beautiful. I'm not even a Rust dev, I'm
mostly in C# land these days, but I appreciate the effort this takes. Well
done!

------
Animats
Imagine what you could do if error messages didn't have to appear as plain
text. You could have arrows, lines, shaded areas, and even multiple fonts.

~~~
taneq
What would this gain us, other than visual clutter and compatibility issues
between IDEs?

~~~
Animats
Better ways to display non-local problems. Rust's borrow checker detects many
errors that reflect inconsistency between two places far apart in code. This
is hard to display.

------
zalmoxes
Inspired by Elm?

~~~
squiguy7
Yes, here is a quote from the post:

> Those of you familiar with the Elm style may recognize that the updated
> --explain messages draw heavy inspiration from the Elm approach.

~~~
corysama
Example:
[https://twitter.com/GregorySchier/status/732830868562182144](https://twitter.com/GregorySchier/status/732830868562182144)

------
IshKebab
This is great! Why keep the row/column numbers at the end of the source file
though? Aren't they redundant (IDEs shouldn't be parsing command line output
anyway so they don't need it).

------
nneonneo
This focus on compiler usability is really fantastic. C calls these "compiler
diagnostics" for a reason - they should help the programmer diagnose and fix
the problem. I loved it when Clang started making C errors sane (and getting
GCC to introduce better messages too!), and I'm glad to see Rust take the next
step. Since I'm stuck in C++ for the time being, I'm (selfishly) hoping that
Clang takes a page from these new Rust errors - these sorts of diagnostics
would look great on C++!

------
marsrover
Not related to this article, but I was looking through the Rust survey
mentioned at the bottom of the article and was surprised at the amount of
people using it for web development.

I'm not very knowledgeable about Rust but I guess I assumed it would not be
the best technology to use in that space. Is Rust really that prevalent in web
development?

~~~
fizzbatter
That's mainly my goal as i learn Rust. It's been a difficult learning
process[1], but i persist because the code i write feels simply more correct.
I also think as time goes on frameworks will improve the ease of use, much of
the ecosystem is very young.

Even better _(or more crazy, heh)_ , i plan on using Rust for clientside as
soon as we have a feasible Rust -> DOM api bridge.

[1]: My learning process was mainly involved in the type system, when writing
my own libraries. Not so much to do with basic web development.

------
mrich
Great to see an improvement over the already improved error reporting
established by clang and later adopted by gcc.

However I don't understand why backticks are still being used - they tend to
look ugly especially when pasting them into emails etc.

~~~
kibwen
Backticks aren't used anywhere in the language itself so they're an obvious
choice for a delimiter, and such usage has been popularized by markdown.

------
Symmetry
That looks really cool and I'll have to give learning Rust another try when
this lands. Also, the title was pretty wonderful. I spent a bit thinking about
it before looking at the domain and realizing what it had to be.

------
knodi
damn... thats nice. Can't wait to dive into it.

------
hyperpape
Do I understand correctly that since this is in the current nightlies, it's
slated for 1.12? So, sometime in October?

~~~
steveklabnik
Yes, current nightlies are 1.12. Anything can happen before release, though,
so in theory, it's not guaranteed to land in 1.12 until the day that 1.12
forks off from master.

------
miguelrochefort
Nothing that Visual Studio and C# doesn't do.

