I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.
I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just means that if you already know those, you will have to learn new concepts to learn Rust, which can be surprising if you aren't told about it ahead of time, particularly when you already know several languages that don't use traits.
I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor.
ADTs are Abstract Data Types[1][2][3]:
> ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List is actually implemented.
In the context of Rust it means that the traits, structs and enums are ADTs, while the impls are Data Structures.
Having structs and enums be the way they are in Rust (simplistic and with little extensibility beyond implementing traits) is that pattern matching[4][5] and destructuring is cheap and built in. Pattern matching becomes specially useful when combined with sum types/tagged unions/enums[6][7][8]. On the other corner you have Scala which lets you implement specific interfaces to allow structuring and destructuring for arbitrary types, but that has the same problems as overriding constructors in C++: the performance implications of pattern matching is impl dependent and hidden at the point of calling.
ADTs are only concerned with the "shape" of the data and what interactions you can have. It is related to classical OOP in the sense that the "interactions" you can have are equivalent to the message passing from the original conception of OOP[1].
The distinction is similar to database design in SQL: the Schema is how the data is laid out and what the relationship between tables is (ADTs) while the queries is the operations performed on them (traits). On the other hand, in OOP there's a higher reliance on encapsulation, making behavior an integral part of what the class is and using inheritance for expansion. When all you have is ADTs, you _can't_ have inheritance, so you end up using composition (which is generally considered better design) and you are more likely to rely on the creation of "new-type" container types for everything. You think of them as a way to describe what the data is, not how you interact with it.
Apologies if this is a bit hand-wavy, I'll try to write a more thoughtful answer at a later time.
