I hadn't seen the roadmap changes. They address a lot issues I had, especially the argument modes.

I'm sure camel casing will be controversial, but it makes sense given that Rust's primary audience is Mozilla, where camel case is the enshrined naming convention for its C++, Java, and JavaScript code. Python's standard library is an ugly example of what happens when the language community can't settle on one convention.

Also, I wonder why 21st century languages still use "&&" and "||" operators. Python's "and" and "or" operators are easier to read (for English speakers) and type. They don't require shifting of distant keys. "and" has two home row characters. "or" has fewer keystrokes than "||". :)

because symbolic operators are more visually distinct than alphabetical ones.

Instead of angled_brackets<> they should probably try to go with D's style of templates[1], which uses an operater !, to signify its use.

Also, I personally believe that camel case for type names would be a net loss; the underscore separates the words nicely, and I think it's pretty clear from the syntax what is and is not a type name (in my extremely limited experience).

[1]. http://dlang.org/templates-revisited.html

What I like about camelcase is that it confers the same kind of visual classification to types as to certain other things.

Back in the day, I used ObjectPascal, where we used camelcase for everything: function names, variables, types. Borland set an early precedent by prefixing many class types with the letter T, thus to visually distinguish them from other things: So you had TWindow, TButton, etc. This system makes sense when you see it in practice:

    function GetParent(Window: TWindow): TWindow;
    begin
      ...

While a bit crude, I feel the same kind of visual differentiation is needed for a language like Rust.

Ruby has some syntactic oddities I like precisely because they provide visual classification: "@" for instance variables and "@@" for class variables:

    class User
      @@max_name_length = 32

      def initialize(name)
        raise "Error" if name.length > @@max_name_length
        @name = name
      end
    end

The current "old-style" Rust code quickly becomes a uniform sea of lowercase to me, as does Stroustrup-style C++. It gets worse due to a quirk of mine to name things verbosely. So instead of variables like "u" to represent a user, I spell out "user". With all lowercase it gets odd:

    fn save(user: user) {
      ...
    }

While Rust have types and variables living in separate namespaces, all-lowercase names introduces the possibility of ambiguity and possibly makes some things impossible in the future, I think; consider:

    let foo = user.new();

It looks like a method call "new()" on an instance "user". But what if you could call methods on types? With the discussion about the "::" operator becoming ".", such a distinction would become impossible without introducing a new operator. With camelcase it becomes obvious what's what:

    let foo = User.new();