4 ms·
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
by LegionMammal978 2y ago
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.
- pimeys 2y agoAlso tracing and rust-opentelemetry gives you a pretty wild ride if needing to do something more special with them.
- jms55 2y agoThis 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.
- unshavedyak 2y agoOne 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.