This isn't wrong, but it seems to be putting the cart before the horse: even with limitations, having generics is still an improvement over not having them, in

This isn't wrong, but it seems to be putting the cart before the horse: even with limitations, having generics is still an improvement over not having them, in terms of one's ability to build type-safe abstractions (i.e. Rust would be a far weaker language without them). For instance, one can write a complicated lock-free data structure that works with any type T, doing the effort to optimise the atomic orderings and avoid leaks (etc.), all without forcing dynamic type casts or unnecessary allocations on downstream users. > The way the Rust compiler works it isn't possible without specifying various bounds on the traits. This is an explicit choice: C++-style check-at-use-site results in some seriously ridiculous error messages, and there's no boundary between implementation and signature, meaning a change to some small detail (and even syntax, in C++) in the implementation can accidentally cause downstream code to fail to compile. It is definitely annoying some times, but Rust, and most other languages with some sort of templates/generics, thinks the benefits outweigh the cost. > And there is no specialization, which is a severe limitation. Indeed, it is a limitation that the team recognises and is working on: https://github.com/rust-lang/rust/issues/31844 https://github.com/rust-lang/rust/issues/31844 (Parts of which are already available in the nightly releases.)