That’s all it is, now you will see what I mean when I dislike huge code bases, as in algebra we factor the code down to small sensible units. Weird in code it’s called re-factor, but essentially it’s factoring.
The other thing to consider is types (like i32 or MyStruct etc.) These should be something and something that is unique and has a particular purpose, easily understood.
Then traits, these are traits of a type, so a vector of some stuff may need to be sorted, so say a vector of u64 integers. For the vector sort to work, it will demand the type is order-able, or can be ordered. This generally means defining a less than function. This less than function is part of the order-able trait. so the function can say, hey I am a vector sort function and I demand the types in the vector have the order-able trait defined, so I can know when I order them then they behave as the designer of the type has allowed for.
People go trait mad, but like algebraic methods you do not need many, possibly 12-18 to satisfy nearly all of maths.
We will also have serialisable traits for types we wish to serialise and send over the network to be de-serialised (or parsed) at the other side.
So lots of power, but keep code small and traits minimal and valid and then things fall in to place. It’s hard but should be as the code is begging you to find the fundamental algorithm/function to express clearly your intent. Doing that is hard but surprisingly liberating as you factor down the mess into a stunning small and reusable algorithm that does exactly what it should and has a clear name.
Lots of fun, but not under time pressure 