> Type inference on declarations but, not function parameters, WAT! This is a hard restriction in place on purpose. The compiler could perform inference for th

> Type inference on declarations but, not function parameters, WAT! This is a hard restriction in place on purpose. The compiler could perform inference for the input and output types as part of the language but that means that the actual low level signature of your function could change by changing either the implementation or the callers. This is a compromise we must have to avoid surprises in real programs that have public APIs. On the flip side the compiler doesn't have this restriction for inferring the return type. If you write a function signature `fn foo() -> _` with a body that can resolve to an unambiguous type, the compiler will give you a structured suggestion for the correct type. This way you get the benefit of inference when developing and the benefit of type safety and unambiguous documentation of your code at the cost of mild inconvenience. > Array's by themselves are nearly useless, might have just made Vec<> the default array type. I'm not sure what the actionable recommendation is here. Is it to have made [] the syntax for Vec? If so, that would have made Vec special from the language's point of view, when it doesn't need to. Today you can reimplement all of Vec in your own Rust code, but you can't for arrays, because the compiler and language need specific memory layout information about them. > Mismatch braces Could you expand? I'm intrigued what you mean by this. > Trait declarations that are scattered everywhere rather than being centralized like a C++ class. This enables very flexible design and composition of behavior. It feels very weird when coming from an OOP background, but I've come to prefer it after a while.