I will reply point by point. I think all of these are good FAQ materials. Thanks for that. Yes, Rust does type inference. Yes, Rust uses "name: type". This wil

I will reply point by point. I think all of these are good FAQ materials. Thanks for that. Yes, Rust does type inference. Yes, Rust uses "name: type". This will not change. Copy can be considered "type of type", aka kind. "impl kind for type" is the syntax for that. Not "type: kind", because type can belong to multiple kinds. "#[derive(Copy)]" is a macro that generates "impl Copy for Info". There are two ways to define methods. One on types, the other on traits, another "type of type". Drop is a trait. Drop::drop is a method that can be called on any type that belongs to Drop. Rust uses "->". This will not change. "name" is a string view, not a string. "name.to_string()" converts a string view to a string. Creating a string allocates, creating a string view doesn't. Rust convention is snake cased method names. This will not change. Yes, Drop::drop is a special case. There was a try to change this, but the conclusion was that it's not worth the effort. Sorry. "fmt::Show" is a trait. "fmt::Show::fmt" is a method defined in the trait. It may be referred by less qualified name, "Show::fmt". No place in the original article says "Show::fmt" is a trait. It is a method. "mut f: T" and "f: &mut T" have completely different meanings. See below. "f" must be "mut" here because you write to the formatter, which can mutate the formatter. There can be many formatters, one formatter may write to the console, but another formatter may write to the memory, a growable buffer owned by the formatter. For later you definitely want "mut". In Rust, a dot is used for fields and methods, a double colon for else. This distinction is useful, because in Rust a dot can dereference a pointer, that is, both "." and "->" in C are written ".". No such thing for a double colon. This will not change. Ampersands are borrow operators. That's why "black_hole" drops, but "fmt" method does not drop a formatter. In "let mut x", it is "let (mut x)", not "(let mut) x". "met" and "mlet" do not make sense because "mut" is not part of special "let mut" syntax. "mut x" in "let mut x" and "mut value" in function arguments are exactly same constructs. You can also do "let (mut x, y)", or "let (x, mut y)". This will not change. "mut f" means you can assign to "f". "f: &mut" means you can mutate through "f", for example assigning to "f.buffer". You can't assign to "f", to do that use "mut f: &mut". This is exactly same as distinction of "const T * v" and "T * const v" in C. The former is written "v: &mut T", the later "mut v: &T". "T * v" is written "mut v: &mut T". This will not change. Yes, a string view does not implicitly convert to a string, because it is an allocating operation. This will not change. There is a change in queue that implicitly convert a string to a string view in certain places to improve usability. There is no way to define Bob as always living on the heap. You can alias, aka typedef, using "type Bob = Box<Bob_>". Then Bob always lives on the heap, which you can convert to value Bob_. This will not change. There is a change in queue that lets you use "box expr" instead of "Box::new(expr)" to improve usability. This also can be used with Rc, RefCell, etc. Don't bolt too soon, Rc and RefCell are rarely needed. As you can see, there are planned changes to improve the syntax, but most syntax you complain about is that way for good reasons, and will not change by 2.0, likely will not change ever. Syntax improvement suggestions after you understand what the syntax means is of course very welcome, although for 1.x you can't make a backward-incompatible change.