[jpd]

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

[lobster_johnson]

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();