> leaving off the semicolon on the last statement causes
> that to be the return value of a function.
This is imprecise. Leaving off the semicolon on the last statement of any block causes the block to evaluate to the result of that statement, and functions are blocks. This is familiar from any other everything-is-an-expression language (mostly functional languages, and Ruby as well) and means that, for example, Rust doesn't need both an `if` construct and a ternary operator (as C does), which ultimately means less syntactic complexity (which is what the grandparent is commenting on). Furthermore, the fact that Rust is statically-typed and that it requires function signatures to be explicitly typed means that accidental implicit return values don't invisibly change the semantics of your program as they can in dynamic languages or languages with whole-program type inference. If you forget a semicolon, it will be a compiler error.
> functions can't capture free variables in lexical scope
This is because functions are allowed to be mutually-recursive, which means that you don't require forward declarations in the language (again, reducing syntactic complexity). Furthermore, closures introduce their own costs when operating at the systems level. AFAIK Rust and C++ are the only languages that manage support for closures without requiring heap allocations, and Rust additionally guarantees that your closures can close over references without accidentally allowing the closure to outlive the referent, something which is an important concern when using C++ closures.
> try reading some non-trivial Rust code that uses generics
> - it's just as incomprehensible and unmaintainable as C++
Rust generics are enormously less powerful than TMPL. They're also much more strongly-typed (good for maintainability), produce good error messages rather than the infamous template spew (good for maintainability), and produce errors at the definition site rather than the use site, thus requiring many fewer tests (good for maintainability).
