Ultimately I need to spend some more time with it. I'm sure it's fine, I just find it jarring. One major issues is the official tutorial doesn't explain all possible variances of syntax for declaration in one place so my brain wasn't given a chance to compare them side by side.

Also i'd much rather live without type inference, so I guess rust gives me that option. I'm just too neurotic (low level networking code/parsers/etc) to not specify types.

    let mut monster_size: int = 50;

I'd really really just like the type to be first.

    let mut int monster_size = 50;

But wait, there are yet more options:

    let monster_size = 50i32; 

Boxes are just plain confusing on first sight. They make pointers look like a lucid breath of fresh air.

    let owned = box 10i;
    let borrowed = &20i;

    let sum = *owned + *borrowed;

I find options in a language quite distressing (see also perl). I'm also not sold on the mut keyword and i'm likely to become confused when one gets to complex types.

Don't get me started on the automatic dereferencing. That's seriously confusing.

Is there a rule of thumb for when I am meant to use which of these? can i use the type annotation anywhere i use a number as a literal?

Raw string literals:

    > They are written as r##"blah"##, with a matching number of zero or more # before the opening and after the closing quote    

Why? Why the optional number of #'s?

Syntax extensions? !

Why is print a syntax extension? why isn't it in the library? if it is a macro why are we running around putting ! at the end of them... why does it matter? Why do that?

I prob don't know what I'm talking about but that's my initial impression from last week

     Why? Why the optional number of #'s?

Code generation. You can nest raw literals within raw literals.

     Boxes are just plain confusing on first sight.

They are special way to allocate values. They are verbose so that programmers won't use them as often. Think of them as a speed bump.

The "let monster_size : int = 50"/"let monst_size = 50i32" is an example of special cases for numeric values. For other types, only the first style is available. I would imagine that it's a shortcut to let you specify easily what kind of representation you want for a numeric value in a less noisy way (since numeric values don't have explicit constructors).

Boxes and lifetimes get a bit used to, but comparing Perl and Rust is, I feel, quite unfair. Rust's syntax is much smaller than Perl's, and from what I've seen the team has taken pains to make it smaller and more regular.

As for println!, it's a macro which gives you compile-time checks on your format string (same as OCaml), which is very nice.

The variable number of #s is in case the string contains some number of #s.

print is a macro so it can be strongly typed and checked by the compiler. As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.

Putting the type of a variable at the end is common in new C-likes. Go does it too. In the case of Rust, I'm pretty sure it's inherited from ML. It avoids a lot of the problems and complexities caused by C's type keywords (see: typedefs of pointers to functions; const pointers to values and pointers to const values; etc.).

> As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.

No, it's very necessary, as macros actually take arbitrary token sequences as an 'argument', so there's no guarantee that the contents will parse as Rust code (e.g. https://github.com/huonw/brainfuck_macros), furthermore, macros can transform this argument into arbitrary code.

Hence it's nice to have an in-source marker to avoid humans and compilers having to work out if a certain name has strange semantics (particularly for compilers, to avoid having to intertwine parsing and name resolution: makes this simpler).

While this isn't exactly the same, the convention of appending "!" in scheme/racket to denote a function that mutates a value is helpful in my opinion. You don't absolutely need it, but reading through your code and easily identifying where your values can change is nice.

> it seems unnecessary to me, too.

It is important for syntax highlighters.