On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library.
I understand why it is this way but it is very much not ergonomic
I think that what is lost in the conversation when this topic comes up is that the current macro alternatives, macros by example and procedural macros, are stop-gap features: the first is what was available in 1.0 that got stabilized with the explicit intent to deprecate in eventually (its replacement is an ongoing effort[1]) and the later is a minimal stabilization of compiler internals that had proven to be useful both internally and in nightly crates, where an API surface that we didn't mind maintaining into the future was stabilized.
The entire macro space in Rust (just like async/await) is in MVP status: they are available and useful already, but their current feature set and approachability isn't the end-state.
I know some will read that and think to themselves "Great! More changes to the language! See, they can't help themselves.", but these changes are about removing restrictions and tapering edges.
I understand why it is this way but it is very much not ergonomic