5 ms·

The example of an error message in the blog post is the kind of thing that makes me seriously consider trying out rust. It's excellent. Are most rust error mess

The example of an error message in the blog post is the kind of thing that makes me seriously consider trying out rust. It's excellent. Are most rust error messages like that?

ChrisSD 7y ago
Yeah pretty much. A lot of effort goes into trying to make error messages as clear and useful as possible. Also `rustc --explain` can give you more general details about the class of error and there's a website that does the same. E.g. for error E0502 mentioned in the article: https://doc.rust-lang.org/error-index.html#E0502 https://doc.rust-lang.org/error-index.html#E0502. It's still possible to hit some edge cases where error messages aren't as helpful as they could be. But these are considered bugs and so will hopefully be fixed.
steveklabnik 7y ago
Most of them are, yes. Some of them are not. We treat bad error messages as bugs, and track them, and have a few dedicated contributors working to make them better all the time.
- kibwen 7y ago
  Worth noting that Rust tries to set a high bar for error messages, so not just bad, but even pretty-okay-but-could-be-better error messages also get tracked as bugs. As a result, 1/6th of all open bugs in the Rust issue tracker are "diagnostics" (i.e. error messages) bugs, making it the single largest category (AFAIK): https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-diagnostics https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
azdle 7y ago
In my experience, the vast majority are exactly like the error they show. Some are even better. I haven't hit a warning in ages that hasn't been able to be auto fixed by `cargo fix`. However not all of them are. Back in the pre-async/await days you'd end up with some really gnarly implicit types in some really big functions with lots of returns. Then sometimes you'd make a mistake on one of the returns and the compiler would assume that your mistaken type was the right one & point out all the places where the actually correct type was returned. Then you'd have to go hunt for where you needed to add a `as Box<Future<Item = _, Error = _>>` to get it to compile again. I haven't hit any issues like that since I started converting the gnarly stuff to infinitely simplier async/await code, but I have to imagine those kinds of issues are still lurking in other areas where you can't get away from complicated code. Even with that I whole-heartedly recommend anyone that's thinking about it just go try it out and/or read some of the book. It's a delightful language to work with. I have way more fun working with Rust than I have with any other language. It takes care of so much of the BS that I don't want to have to think about, so I can just think about the interesting stuff.
- estebank 7y ago
  Thanks for the kind words. I would say that subpar errors fall in one of two camps: incredibly uncommon (so we haven't "exercised" that muscle to clean them up) or incredibly hard to deal with. I monitor the issue tracker so if you do encounter a confusing error, file a ticket, we treat them seriously.
  - azdle 7y ago
    Thank you for your hard work on rust. The intelligent error messages are a significant part of what makes rust such a joy to use. And will do, if I encounter them.
dx87 7y ago
Yep, I think the only error messages I've seen that weren't easy to read are the old Futures error messages that could easily have type signatures multi-lines long, and some macro errors that say something like "this macro generated an error outside this crate". Even without something like a language server or full-fledged IDE, you can do "error driven development" where the compiler tells you what line has an error, and gives you a suggestion on how to fix it.
estebank 7y ago
I'm one of the people working on UX and ergonomics. I would say that we aim even higher than what that output in particular shows. If an error could possibly be confusing to people, it gets reworked. Years past we spent a lot of time honing general common errors to a pretty neat level, then we moved on to detecting specific cases. I would say that the quality of the output is a bimodal distribution with a cluster of really high quality for common errors, and a big but shrinking cluster of confusing errors for more advanced features. To give an example, async await relies on three things: syntactic sugar (which means there's generated code that's not in the user written code), associated types (that had badly confusing type errors) and impl Trait (that had confusing type errors). The later two features didn't receive much love for a while because they were advanced features that a newcomer would be unlikely to hit, with exceptions for crates doing interesting but confusing things with them to provide a nicer API. But when the dust started to settle aroune async/await it was clear to me that people would be seeing the stabilization announcement, consider trying rust and jump straight to very arcane errors that would now be very easy to hit. This made me and a few others actually spend the time to drastically (if not entirely) improve those errors ahead of async/await stabilization, with the nice side effect that those features are also up to the level of quality that we want for newcomers. The syntactic sugar part also plays a part on how you explain succinctly and clearly that the type or inference error you're seeing comes from a return type materialized out if the aether, but I think we've gotten good at that. If you will be picking up Rust to try it out, I encourage people to use nightly, not because of features but rather because we have diagnostics improvements daily and they can be the difference between having to read the book to understand how to fix your issue and just following the compiler's lead. As an example, you can see this recently landed PR: https://github.com/rust-lang/rust/pull/68267 https://github.com/rust-lang/rust/pull/68267
- wpietri 7y ago
  I really appreciate that people are thinking about language ergonomics in a serious way. I've recently been using Flutter and it's a delight to get an error message like "you did X, but Y was uninitialized, so you need to put a call to Y.Z in your code first". When my problem is some conceptual mistake, a traditional error message, like "null pointer error in Y" just confuses me, because I don't even know what Y relates to what I'm doing. I love that you and others are taking the time to see what really went wrong. Partly because it solves my immediate problem, but also because I know that's exerting backpressure on confusing language and library features, which I hope will drive more platform improvements down the road.
shepmaster 7y ago
Most are that good, or better. I actually debated putting that error because it's one that doesn't have a "help:" line that actively suggests how to fix it. Some errors are admittedly worse, and people like estebank are actively working on improving them.
- estebank 7y ago
  FWIW, I think it was a good choice to showcase the underlying feature as opposed to showing off the diagnostics :)
- carapace 7y ago
  You're the author of the blog post? Dunno if this is something you care about, but with JS turned off the code boxes are omitted (with no placeholders or other clues that something is missing.)
  - shepmaster 7y ago
    I am! It's something I care about, but not sure if there's something I can do about it. The code blocks are powered by a `<script>` tag from GitHub's Gists. Unfortunately, I don't have the ability to edit that post without Wordpress completely removing those tags (I don't have appropriate permissions). I can ask for them to put `<noscript>` tags, but don't know if that will really help.

The example of an error message in the blog post is the kind of thing that makes me seriously consider trying out rust. It's excellent. Are most rust error messages like that?

ChrisSD 7y ago

Yeah pretty much. A lot of effort goes into trying to make error messages as clear and useful as possible. Also `rustc --explain` can give you more general details about the class of error and there's a website that does the same. E.g. for error E0502 mentioned in the article: https://doc.rust-lang.org/error-index.html#E0502 https://doc.rust-lang.org/error-index.html#E0502. It's still possible to hit some edge cases where error messages aren't as helpful as they could be. But these are considered bugs and so will hopefully be fixed.

steveklabnik 7y ago

Most of them are, yes. Some of them are not. We treat bad error messages as bugs, and track them, and have a few dedicated contributors working to make them better all the time.

kibwen 7y ago
Worth noting that Rust tries to set a high bar for error messages, so not just bad, but even pretty-okay-but-could-be-better error messages also get tracked as bugs. As a result, 1/6th of all open bugs in the Rust issue tracker are "diagnostics" (i.e. error messages) bugs, making it the single largest category (AFAIK): https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-diagnostics https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...

azdle 7y ago

In my experience, the vast majority are exactly like the error they show. Some are even better. I haven't hit a warning in ages that hasn't been able to be auto fixed by `cargo fix`. However not all of them are. Back in the pre-async/await days you'd end up with some really gnarly implicit types in some really big functions with lots of returns. Then sometimes you'd make a mistake on one of the returns and the compiler would assume that your mistaken type was the right one & point out all the places where the actually correct type was returned. Then you'd have to go hunt for where you needed to add a `as Box<Future<Item = _, Error = _>>` to get it to compile again. I haven't hit any issues like that since I started converting the gnarly stuff to infinitely simplier async/await code, but I have to imagine those kinds of issues are still lurking in other areas where you can't get away from complicated code. Even with that I whole-heartedly recommend anyone that's thinking about it just go try it out and/or read some of the book. It's a delightful language to work with. I have way more fun working with Rust than I have with any other language. It takes care of so much of the BS that I don't want to have to think about, so I can just think about the interesting stuff.

estebank 7y ago
Thanks for the kind words. I would say that subpar errors fall in one of two camps: incredibly uncommon (so we haven't "exercised" that muscle to clean them up) or incredibly hard to deal with. I monitor the issue tracker so if you do encounter a confusing error, file a ticket, we treat them seriously.
- azdle 7y ago
  Thank you for your hard work on rust. The intelligent error messages are a significant part of what makes rust such a joy to use. And will do, if I encounter them.

dx87 7y ago

Yep, I think the only error messages I've seen that weren't easy to read are the old Futures error messages that could easily have type signatures multi-lines long, and some macro errors that say something like "this macro generated an error outside this crate". Even without something like a language server or full-fledged IDE, you can do "error driven development" where the compiler tells you what line has an error, and gives you a suggestion on how to fix it.

estebank 7y ago

I'm one of the people working on UX and ergonomics. I would say that we aim even higher than what that output in particular shows. If an error could possibly be confusing to people, it gets reworked. Years past we spent a lot of time honing general common errors to a pretty neat level, then we moved on to detecting specific cases. I would say that the quality of the output is a bimodal distribution with a cluster of really high quality for common errors, and a big but shrinking cluster of confusing errors for more advanced features. To give an example, async await relies on three things: syntactic sugar (which means there's generated code that's not in the user written code), associated types (that had badly confusing type errors) and impl Trait (that had confusing type errors). The later two features didn't receive much love for a while because they were advanced features that a newcomer would be unlikely to hit, with exceptions for crates doing interesting but confusing things with them to provide a nicer API. But when the dust started to settle aroune async/await it was clear to me that people would be seeing the stabilization announcement, consider trying rust and jump straight to very arcane errors that would now be very easy to hit. This made me and a few others actually spend the time to drastically (if not entirely) improve those errors ahead of async/await stabilization, with the nice side effect that those features are also up to the level of quality that we want for newcomers. The syntactic sugar part also plays a part on how you explain succinctly and clearly that the type or inference error you're seeing comes from a return type materialized out if the aether, but I think we've gotten good at that. If you will be picking up Rust to try it out, I encourage people to use nightly, not because of features but rather because we have diagnostics improvements daily and they can be the difference between having to read the book to understand how to fix your issue and just following the compiler's lead. As an example, you can see this recently landed PR: https://github.com/rust-lang/rust/pull/68267 https://github.com/rust-lang/rust/pull/68267

wpietri 7y ago
I really appreciate that people are thinking about language ergonomics in a serious way. I've recently been using Flutter and it's a delight to get an error message like "you did X, but Y was uninitialized, so you need to put a call to Y.Z in your code first". When my problem is some conceptual mistake, a traditional error message, like "null pointer error in Y" just confuses me, because I don't even know what Y relates to what I'm doing. I love that you and others are taking the time to see what really went wrong. Partly because it solves my immediate problem, but also because I know that's exerting backpressure on confusing language and library features, which I hope will drive more platform improvements down the road.

shepmaster 7y ago

Most are that good, or better. I actually debated putting that error because it's one that doesn't have a "help:" line that actively suggests how to fix it. Some errors are admittedly worse, and people like estebank are actively working on improving them.

estebank 7y ago
FWIW, I think it was a good choice to showcase the underlying feature as opposed to showing off the diagnostics :)
carapace 7y ago
You're the author of the blog post? Dunno if this is something you care about, but with JS turned off the code boxes are omitted (with no placeholders or other clues that something is missing.)
- shepmaster 7y ago
  I am! It's something I care about, but not sure if there's something I can do about it. The code blocks are powered by a `<script>` tag from GitHub's Gists. Unfortunately, I don't have the ability to edit that post without Wordpress completely removing those tags (I don't have appropriate permissions). I can ask for them to put `<noscript>` tags, but don't know if that will really help.