> vec<int> something = new; > might be better than > let something = new vec<int>; I don't think this is right at all. The name of the variable is far

> vec<int> something = new; > might be better than > let something = new vec<int>; I don't think this is right at all. The name of the variable is far more important than its type - ideally, the name of the variable should include a hint as to the nature of its type, whether it's explicit (e.g. parent and child in a tree navigation function are obviously references to the tree node type that is being navigated over) or very lightly suggested (e.g. pluralization, like children for a list of child things). The actual type is of secondary importance, chosen for implementation reasons (e.g. a map might be hash-based or tree-based, or a list might be a view over some other list, synthesized from some foreign collection, or a wrapper around an array in memory). For me, the name of the variable is of paramount importance for understanding the code. The type is very secondary. Types are usually in two buckets: domain-specific (so the name typically is highly relevant to what's being done and is often the same as the type name or an abbreviation or agglutination), or common denominator library types (typically collections, strings, primitives, that kind of thing) where the name of the variable implies the type. The name is the thing that you see over and over again in the code. You also don't get to see the type when you call a method. So readable code needs good consistent names that make type annotations helpful but far from mandatory for comprehension.