6 ms·

Cool blog. I tried playing around with Rust as well on some toy problems, and had a similar experience: cryptic error messages that only made sense in hindsigh

by Fede_V 11y ago

Cool blog. I tried playing around with Rust as well on some toy problems, and had a similar experience: cryptic error messages that only made sense in hindsight. It's an awesome language, but I wish there was a bit more effort put into into making it 'ergonomic'. Of course, it's an open source effort so nobody is owned anything - but useful error messages are incredibly important, especially when the language pushes so many new concepts.

hellofunk 11y ago
A fair but common criticism of new languages. Clojure is famous for this problem as well.
- masklinn 11y ago
  Elm, however, goes the exact opposite and tries to make compiler error messages as helpful as possible to beginners, especially from 0.16 onwards: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants with a whole repository dedicated to non-compiling programs with less than ideal error messages: https://github.com/elm-lang/error-message-catalog/ https://github.com/elm-lang/error-message-catalog/ TBF might be simpler for Elm as it eschews much in the way of type abstractions.
  - bjz_ 11y ago
    Yeah, Elm has a far simpler type system at the moment (no ad-hoc polymorphism for example), so it cuts down on the difficulty of experimenting with new ways of displaying errors. Which I think is a good thing to do, especially seeing as one of the goals of Elm is to make static type systems more 'friendly' to a wider audience. But it is definitely going to push the developers of more complex languages to improve their developer experience - we in the Rust world are certainly taking note!
  - StavrosK 11y ago
    Oh wow, those error messages alone make me want to try Elm. It looks like I could learn the language just from the compiler output.
benashford 11y ago
How could that particular error (using that as an example) be improved? > error: the trait `core::fmt::Debug` is not implemented for the type `T` That pretty much is the problem. It seems the bigger pain point is as you say "they make sense in hindsight", but that's because (as the author acknowledges) of expectations driven by other programming languages. C++ wouldn't have raised an error because the type-checking is done after template expansion, whereas Rust is the other way around. The biggest criticism from me would be the hints underneath advising the author to implement the Debug trait, whereas the solution is to add a trait bound to the code instead. If anything I'd say Rust's compilation errors are above average in both the accuracy of the error message, and helpful hints. The learning curve around concepts such as lifetimes and moved values and other rare features do take time, however.
- deleted 11y ago
  [deleted]
- lhnz 11y ago
  I would like it to say something like "Either the trait `core::fmt::Debug` is not implemented for the type `T`, or it is implemented but the compiler does not know about it in this context." Not sure if that is the language I would use, but that is what I want it to say. Suggesting that I might be able to solve the problem by providing more information to the compiler would help me realise how I could solve the problem. I've had similar problems when developing Rust code, and I wonder whether they would be happy to accept changes to their error messages? My biggest difficulties trying to understand Rust error messages were either with lifetimes or errors emanating from within macros (it is very hard to see what is failing when you have never seen the code itself.)
  - arjie 11y ago
    Interesting. I'd read that code as "For all T, if we have a Buffer<T>, print out the Vec<T>'s elements" and it makes sense that this doesn't work. It isn't that the compiler doesn't know about it, but that T is not constrained within the form to something printable and consequently you can't print it. It would seem more confusing if it had indeed worked, since that would mean (in a semantic sense) that T is auto-constrained to the types that are actually used as T, so you can't reason about the code having the T on its own but only within the context of the larger form. Not arguing or anything about what error messages are valid. I just found your perspective about the "compiler not knowing" interesting and felt like sharing this.
pcwalton 11y ago
We put more effort into error messages than almost any language I know of, except Elm and Haskell dialects. A huge fraction of rustc commits are tweaking error messages for ease of use. Rustc error reporting was deliberately based on that of clang. In particular, I think it is going to be impossible to have error messages for lifetime errors that are solvable without doing at least some background reading.
- Fede_V 11y ago
  I can only offer my point of view as a complete rust novice. Lifetimes are the most intriguing and new aspect of programming in rust - this unfortunately means that when people first start with the language and they run into non-obvious errors, they will need a little handholding. Google/stackoverflow of course help, but, as an expert, I think you may be a bit biased by your own experience as to how helpful the compiler errors actually are.
  - masklinn 11y ago
    > Lifetimes are the most intriguing and new aspect of programming in rust - this unfortunately means that when people first start with the language and they run into non-obvious errors, they will need a little handholding. I genuinely have no idea how you'd even go around improving lifetime errors, if somebody manages to crack that one I'd probably be willing to set up a recurring donation to whatever they wish.
    - steveklabnik 11y ago
      There's been at least one promising idea floating around: using an IDE to draw out lifetimes, so you can see how they overlap. Something like slides 172/173 of http://www.slideshare.net/nikomatsakis/rust-mozlando-tutorial http://www.slideshare.net/nikomatsakis/rust-mozlando-tutoria...
      - Fede_V 11y ago
        That would be fantastic!

by Fede_V 11y ago

hellofunk 11y ago

A fair but common criticism of new languages. Clojure is famous for this problem as well.

masklinn 11y ago
Elm, however, goes the exact opposite and tries to make compiler error messages as helpful as possible to beginners, especially from 0.16 onwards: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants with a whole repository dedicated to non-compiling programs with less than ideal error messages: https://github.com/elm-lang/error-message-catalog/ https://github.com/elm-lang/error-message-catalog/ TBF might be simpler for Elm as it eschews much in the way of type abstractions.
- bjz_ 11y ago
  Yeah, Elm has a far simpler type system at the moment (no ad-hoc polymorphism for example), so it cuts down on the difficulty of experimenting with new ways of displaying errors. Which I think is a good thing to do, especially seeing as one of the goals of Elm is to make static type systems more 'friendly' to a wider audience. But it is definitely going to push the developers of more complex languages to improve their developer experience - we in the Rust world are certainly taking note!
- StavrosK 11y ago
  Oh wow, those error messages alone make me want to try Elm. It looks like I could learn the language just from the compiler output.

benashford 11y ago

How could that particular error (using that as an example) be improved? > error: the trait `core::fmt::Debug` is not implemented for the type `T` That pretty much is the problem. It seems the bigger pain point is as you say "they make sense in hindsight", but that's because (as the author acknowledges) of expectations driven by other programming languages. C++ wouldn't have raised an error because the type-checking is done after template expansion, whereas Rust is the other way around. The biggest criticism from me would be the hints underneath advising the author to implement the Debug trait, whereas the solution is to add a trait bound to the code instead. If anything I'd say Rust's compilation errors are above average in both the accuracy of the error message, and helpful hints. The learning curve around concepts such as lifetimes and moved values and other rare features do take time, however.

deleted 11y ago
[deleted]
lhnz 11y ago
I would like it to say something like "Either the trait `core::fmt::Debug` is not implemented for the type `T`, or it is implemented but the compiler does not know about it in this context." Not sure if that is the language I would use, but that is what I want it to say. Suggesting that I might be able to solve the problem by providing more information to the compiler would help me realise how I could solve the problem. I've had similar problems when developing Rust code, and I wonder whether they would be happy to accept changes to their error messages? My biggest difficulties trying to understand Rust error messages were either with lifetimes or errors emanating from within macros (it is very hard to see what is failing when you have never seen the code itself.)
- arjie 11y ago
  Interesting. I'd read that code as "For all T, if we have a Buffer<T>, print out the Vec<T>'s elements" and it makes sense that this doesn't work. It isn't that the compiler doesn't know about it, but that T is not constrained within the form to something printable and consequently you can't print it. It would seem more confusing if it had indeed worked, since that would mean (in a semantic sense) that T is auto-constrained to the types that are actually used as T, so you can't reason about the code having the T on its own but only within the context of the larger form. Not arguing or anything about what error messages are valid. I just found your perspective about the "compiler not knowing" interesting and felt like sharing this.

pcwalton 11y ago

We put more effort into error messages than almost any language I know of, except Elm and Haskell dialects. A huge fraction of rustc commits are tweaking error messages for ease of use. Rustc error reporting was deliberately based on that of clang. In particular, I think it is going to be impossible to have error messages for lifetime errors that are solvable without doing at least some background reading.

Fede_V 11y ago
I can only offer my point of view as a complete rust novice. Lifetimes are the most intriguing and new aspect of programming in rust - this unfortunately means that when people first start with the language and they run into non-obvious errors, they will need a little handholding. Google/stackoverflow of course help, but, as an expert, I think you may be a bit biased by your own experience as to how helpful the compiler errors actually are.
- masklinn 11y ago
  > Lifetimes are the most intriguing and new aspect of programming in rust - this unfortunately means that when people first start with the language and they run into non-obvious errors, they will need a little handholding. I genuinely have no idea how you'd even go around improving lifetime errors, if somebody manages to crack that one I'd probably be willing to set up a recurring donation to whatever they wish.
  - steveklabnik 11y ago
    There's been at least one promising idea floating around: using an IDE to draw out lifetimes, so you can see how they overlap. Something like slides 172/173 of http://www.slideshare.net/nikomatsakis/rust-mozlando-tutorial http://www.slideshare.net/nikomatsakis/rust-mozlando-tutoria...
    - Fede_V 11y ago
      That would be fantastic!