Hacker News Reader

Comment by LegionMammal978 | Hacker News Reader

Yeah, trait-heavy code is one of Rust's weaker points in practice. I find tower and some of the database crates to be some of the worst offenders: even knowing the language pretty well, I've often gotten lost in a maze of projections and blanket impls when an error occurs. There's no easy way to trace the implementation back to the intended behavior, to compare the expected and actual outcomes.

View on HN

This has actually gotten better recently. You can now implement custom error diagnostics.

E.g. Bevy implements a trait (QueryData) for tuples of up to 32 items (A,) + (A, B) + (A, B, C)...

If you went over that 32 items, you used to get a confusing error about not your type not implementing QueryData.

Now you get a nice error message explaining the common reasons why this your type does not satisfy the trait.

One of my annoyances is for something like `impl Foo for T: Deref<U>, U: Foo`. Ie a Foo impl for something that can deref to another type, which impls Foo. Eg an Arc, Box, etc. So now that you impl that to support, say, Box - well now if something fails to impl Foo, you'll instead get an error about it not being a Box (iirc, been a while). Ie, my memory is old so forgive me, but the error says something to the effect of your `T` type not being Box<T>`, instead of it simply saying that your T doesn't impl Foo.

I ran into this confusing error so many times i just stopped doing blanket deref impls and instead just impl it for `Box<T>` directly. Doing that avoids the weird error entirely.

Still, i love Rust. However it, like any lang, is not perfect. Nor should it be.

Also tracing and rust-opentelemetry gives you a pretty wild ride if needing to do something more special with them.

Reply on news.ycombinator.com