I'm very critical of the rustc diagnostics (if I wasn't, I wouldn't find reason to spend time on them), but then I see someone calling them "inscrutable" and I feel very confused. What are they comparing against? Tell me! I want to copy their homework!
[#]RustLang #Rust
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber People who are inexperienced with Rust get sidetracked by something like a complex trait bound on a future. Actually, the error message is perfect, but because the type in question is a complicated one, they focus on that, rather than the error itself, or the hint text. Later on, they recognize the error pattern as familiar, even if the types are funky, so the "inscrutable" bit just melts away.
=> More informations about this toot | More toots from dpom@fosstodon.org
@ekuber I will say that there are a lot of cases where type mismatch errors confuse me on what is the "expected" vs "found" type. Reproducing a trivial error, I'm not even sure why. Maybe when dealing with generics, complicated types that get elided, or less direct type inference?
=> More informations about this toot | More toots from epage@hachyderm.io
@epage I try to point at the "expected" and "found" places explicitly. If you come across cases when that doesn't happen, I'd love to see them.
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber @epage Usually error messages are great, but I managed create this a few hours ago. The actual difference is in expected live times it captures. I tried to make a less convoluted example but couldn't do it quickly so moved in with fixing.
=> More informations about this toot | More toots from manpacket@functional.cafe
@manpacket yeah. "One type more general than the other" is a thorn on my side that I don't yet know how to address
=> More informations about this toot | More toots from ekuber@hachyderm.io
@ekuber hm. my guess to what's happening is that people are very new to rust and very unfamiliar with rust's concepts. they're getting errors about things they've never heard about. why does this code not work? this makes no sense! the errors may be objectively better than what they're used to, but in the other language their experience makes more than up for it.
so in short: the homework is being java, replace rust with java
=> More informations about this toot | More toots from noratrieb@hachyderm.io
@noratrieb @ekuber Yeah, I think the aforementioned person probably wasn't differentiating between language/semantics/compiler/diagnostics and the thing that gets the blame is the diagnostic because that's the bit they see as telling them off.
=> More informations about this toot | More toots from jsbarretto@social.coop
@jsbarretto @ekuber which means flag while there will of course always be space for improvements, you won't be able to entirely fix the problem purely with diagnostics, unless you put the entire rust book in there. challenging you, Esteban
=> More informations about this toot | More toots from noratrieb@hachyderm.io
@noratrieb @jsbarretto look, I'm trying
=> More informations about this toot | More toots from ekuber@hachyderm.io
@noratrieb @ekuber Yeah, exactly. As much as I love "let's educate people with errors", there is a sort of entropy limit to just how concisely you can communicate things that are fundamentally difficult to understand. Every explanation requires assumptions of certain prior knowledge, and I feel like the prior knowledge required for rustc errors to be both useful to beginners and also not annoying word salad for more advanced users is, at minimum, "I have read the first few chapters of The Book".
=> More informations about this toot | More toots from jsbarretto@social.coop
@ekuber they are comparing it to the error messages they get when using much, much simpler languages.
=> More informations about this toot | More toots from hisham_hm@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini