4 ms·

[1] finally explains to me why so many new languages like Scala and Kotlin and Go use the right-hand side declaration syntax. And it also automatically aligns m

[1] finally explains to me why so many new languages like Scala and Kotlin and Go use the right-hand side declaration syntax. And it also automatically aligns multiple variable identifiers in one column.

pcwalton 14y ago
In Rust the choice was much simpler: we didn't want to use the lexer hack, and we wanted to avoid arbitrary lookahead in the parser. Consider: let hashmap<int,str> x; let x; After parsing the "let" we don't know whether to parse a type (which can be arbitrarily long) or a variable name. Switching to postfix types neatly solves the problem: let x: hashmap<int,str>; let x;
- lobster_johnson 14y ago
  I like how Rust uses colons for the type, compared to Go's colonless syntax. The colon works as a nice visual delimiter. I like a lot about Rust, but one thing I vehemently dislike is how type names are all lowercase by convention. It's unambiguous in variable declarations, but everywhere else it reduces visual information. In most other languages, I immediately know that "Foo" is a type and that "foo" is a variable. Even though Rust allows for omitting the type in many places, it quickly becomes a sea of lowercase for me. This, plus the focus on short keywords/identifiers and C++-style syntax (::, semicolons), makes Rust look a lot gnarlier than Go, overall. It also seems to me that Rust still hasn't fully adopted its "object syntax"? One aspect of Go I really like is how functions can be used as methods and you design entire interfaces associated with a type -- the best of object-orientation without the worst. Rust also does this, but on the whole it seems the current standard library is not designed around this philosophy. For example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away from the OO syntax, or is it simply considered a stylistic choice?
  - pcwalton 14y ago
    You'll be happy to know that these issues are being addressed: * I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.) * The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code. * '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change. * You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system. I'd prefer it if semicolons stayed, however; I think automatic semicolon insertion is more trouble than it's worth, as it ruins people's house bracing styles and causes confusing errors. That said, the way a trailing semicolon changes a block's return value is very confusing, and I'm pretty sure we can fix that issue. [1]: https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces https://github.com/mozilla/rust/wiki/Proposal-for-unifying-t...
    - kibwen 14y ago
      "identifiers are going to lengthen in new code" I'll be holding you to this promise. :) Indeed, what's the point of super-short keywords if not to allow identifiers to be more descriptive while maintaining an 80-column limit?
    - lobster_johnson 14y ago
      Wow. I'm pleasantly surprised that all of my issues are actually being addressed -- I was thinking that I might be in the minority on these points. I need to be paying closer attention to the mailing list. While I love that you are making major changes, I am sure that you are aware that the instability of the language is a problem for many people. I have been watching from the sidelines for a good while now, but aside from testing new builds and reading the developer blogs, I dare not start using Rust for anything. Niko Matsakis's recent blog entry about mutability was particularly disappointing as it seems such a basic idea should have been settled much earlier. I can appreciate the kind of experimental, agile approach to language design, of course; but while Rust is germinating, I have been forced to fall back to Go. I really hope the dust settles soon so the language can stabilize and mature. As for the semicolons, I think a strict, well-defined rule such as the one used by Go is sufficient. Actually, Go is a bit too rigid about semicolon insertion for my taste. The following, for example, will not compile, despite the fact that the ending brace is expected by the parser: house := &House{ color: Green, floors: 3, patio: true } On the other hand, Go is perfectly happy about: import ( "fmt" "io" ) ...but I have not looked into why this is a special case.

pcwalton 14y ago

In Rust the choice was much simpler: we didn't want to use the lexer hack, and we wanted to avoid arbitrary lookahead in the parser. Consider: let hashmap<int,str> x; let x; After parsing the "let" we don't know whether to parse a type (which can be arbitrarily long) or a variable name. Switching to postfix types neatly solves the problem: let x: hashmap<int,str>; let x;

lobster_johnson 14y ago
I like how Rust uses colons for the type, compared to Go's colonless syntax. The colon works as a nice visual delimiter. I like a lot about Rust, but one thing I vehemently dislike is how type names are all lowercase by convention. It's unambiguous in variable declarations, but everywhere else it reduces visual information. In most other languages, I immediately know that "Foo" is a type and that "foo" is a variable. Even though Rust allows for omitting the type in many places, it quickly becomes a sea of lowercase for me. This, plus the focus on short keywords/identifiers and C++-style syntax (::, semicolons), makes Rust look a lot gnarlier than Go, overall. It also seems to me that Rust still hasn't fully adopted its "object syntax"? One aspect of Go I really like is how functions can be used as methods and you design entire interfaces associated with a type -- the best of object-orientation without the worst. Rust also does this, but on the whole it seems the current standard library is not designed around this philosophy. For example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away from the OO syntax, or is it simply considered a stylistic choice?
- pcwalton 14y ago
  You'll be happy to know that these issues are being addressed: * I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.) * The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code. * '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change. * You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system. I'd prefer it if semicolons stayed, however; I think automatic semicolon insertion is more trouble than it's worth, as it ruins people's house bracing styles and causes confusing errors. That said, the way a trailing semicolon changes a block's return value is very confusing, and I'm pretty sure we can fix that issue. [1]: https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces https://github.com/mozilla/rust/wiki/Proposal-for-unifying-t...
  - kibwen 14y ago
    "identifiers are going to lengthen in new code" I'll be holding you to this promise. :) Indeed, what's the point of super-short keywords if not to allow identifiers to be more descriptive while maintaining an 80-column limit?
  - lobster_johnson 14y ago
    Wow. I'm pleasantly surprised that all of my issues are actually being addressed -- I was thinking that I might be in the minority on these points. I need to be paying closer attention to the mailing list. While I love that you are making major changes, I am sure that you are aware that the instability of the language is a problem for many people. I have been watching from the sidelines for a good while now, but aside from testing new builds and reading the developer blogs, I dare not start using Rust for anything. Niko Matsakis's recent blog entry about mutability was particularly disappointing as it seems such a basic idea should have been settled much earlier. I can appreciate the kind of experimental, agile approach to language design, of course; but while Rust is germinating, I have been forced to fall back to Go. I really hope the dust settles soon so the language can stabilize and mature. As for the semicolons, I think a strict, well-defined rule such as the one used by Go is sufficient. Actually, Go is a bit too rigid about semicolon insertion for my taste. The following, for example, will not compile, despite the fact that the ending brace is expected by the parser: house := &House{ color: Green, floors: 3, patio: true } On the other hand, Go is perfectly happy about: import ( "fmt" "io" ) ...but I have not looked into why this is a special case.