Not GP and I know some Java, but not C#. As I get it, in Java generics are little more than sugar coating: they basically check that your are not messing up wit

Not GP and I know some Java, but not C#. As I get it, in Java generics are little more than sugar coating: they basically check that your are not messing up with types. Having a List<String> is not very different (maybe not at all) from having a List<Object> and casting elements between Object and String when you put or get them, except that the compiler can check the types at compilation time. The List code is essentially the same. By contract, a std::vector<std::string> and a std::vector<int> in C++ are two completely different and unrelated classes. Any code they used is compiled twice, once for every value of the template parameter, and of course is optimized independently in each case. So, for example, although the template code is the same, the operation of copying a vector an give very different assembly codes: copying a vector of strings requires to call the copy constructor of each single string in the new vector, but copying a vector of ints basically reduces to calling memcpy() appropriately (thanks to all the appropriate abstractions, so that the compiler knows that to copy an int it is enough to copy its bytes, and this cannot fail due to an exception, and maybe other things). This is one of the great thing in C++ (at least, if you value this kind of optimizations), and it seems that OP misses the point entirely. It gives what is called (when it works) "zero-cost abstraction". You might like it or not, but it makes no sense to judge C++ design choices if you don't consider the ability to do zero-cost abstraction (which, for example, Java does not have).