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.
> 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.
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.)
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.
I still think the error message could be a lot better, as the word 'implementation' is confusing. What's happened here is that Buffer was being used in a for-loop as if it always contained printable types, when actually there was no assurance that this was the case.
Edit: Highly recommend reading the comments of the two people that responded to me, as they're both more correct and more helpful while I was trying to work things out as I wrote my comments.
requires that "i" implements Debug, but
src/x/mod.rs:15 impl<T> Info for Buffer<T> {
does not specify that T must be Debug
hint: you can bound T to Debug:
impl <T> Info for Buffer<T> where T: Debug {
this means the code will only work with types which implements Debug,
but lets you use Debug operations in your methods
Not quite. Rust's generics are instantiated statically - the compiler generates code specific to the type parameters passed in. The compiler must handle cases where it could not find a conforming function implemented for that the type, otherwise no code can be generated. Without the use of traits to constrain types you could get around this by printing a stack trace of the instantiation, but that causes even worse error messages - ie. the ones you see coming from C++ compilers.
> I wonder whether they would be happy to accept changes to their error messages?
People seem to be _really_ split about Rust's current errors: I've heard, in the same day, "Rust has the worst error messages" and "Rust has the best error messages". Trying to figure out how to get the former camp into the latter.
That's usually why I'm always asking for specifics when people make general complaints, I'm trying to dig into the _why_. "Error messages are bad" isn't actionable; "error messages are bad because" often is. This thread was already getting into specifics before I woke up, though :)
Which probably means there's a steep learning curve to them, but they are really useful and informative after that initial learning period is over. If so, tread carefully lest you ruin the latter by catering to much to the former problem.
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.
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.
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.
TBF might be simpler for Elm as it eschews much in the way of type abstractions.