I would recommend trying to be a little less forceful in arguments about a language that you do not yet have first-hand experience with.
In particular, there are two ways in which your "unarguable objective statement of fact" are incorrect. For one, @arielb1 was being a little loose when saying "you can add it even when it is not needed." There are cases in which you can add it in which it is not needed, but there are other cases in which you cannot:
fn foo(_x: u32) {}
fn main() {
let a = 12;
foo(&a);
}
Gives you:
<anon>:5:9: 5:11 error: mismatched types:
expected `u32`,
found `&_`
(expected u32,
found &-ptr) [E0308]
<anon>:5 foo(&a);
^~
<anon>:5:9: 5:11 help: see the detailed explanation for E0308
error: aborting due to previous error
In addition, even if you could always add it when it is not needed, that still wouldn't mean that it's pure noise; since there could still be cases in which it was required to add it, so the absence of the &
would convey information that the argument was not being passed by reference.
So, in those two ways, &
is not pure noise. It does convey information. It tells you when an argument is being passed in by value, which is very important for types that are not Copy
as that means the value is consumed and so you cannot later use the variable in your function, and even for types which are Copy
it can tell you if you care copying the whole type around, or whether the argument is being passed in as just a pointer.
Language design involves tradeoffs. There are some things that you can infer, and some things that need to be made explicit, and many different ways to move around what parts you make implicit and what parts are inferred. Rust went through many iterations of different types of syntax, and different rules about what is explicit, what is inferred, and how coercions work. The current result is the result of many years using and tweaking those rules to find something that strikes a good balance between explicitness and ease of use.
I would recommend that you spend some more time trying out the language, and less time in language design discussions on aspects of the language that are fairly well settled and stabilized.