5 ms·

The one thing which nags me about Rust is the amount of what seem like weird syntax choices, deliberately different from most popular programming languages. Se

by ivoras 12y ago

The one thing which nags me about Rust is the amount of what seem like weird syntax choices, deliberately different from most popular programming languages. See e.g. line 14 in https://github.com/oakes/SolidOak/blob/master/src/ffi.rs https://github.com/oakes/SolidOak/blob/master/src/ffi.rs : let mut fds : [c_int; 2] = [0; 2]; Why not declare the array type as c_int[2]? And why use semicolons instead of commas? There are enough such "wtf?" moments that it causes pause and a sense of weirdness while reading Rust code, if the reader is familiar with other C-like languages (which is not to say that Rust itself is C-like).

vertex-four 12y ago
> Why not declare the array type as c_int[2]? Because a design decision was made that the type should look like the instantiation of that type. Same with structs and enums. > And why use semicolons instead of commas? Because this is "two elements both containing 0", not the array [0, 2]. Semicolons are used for that.
killercup 12y ago
> if the reader is familiar with other C-like languages I like to think that Rust wants you to be familiar with C and ML syntax and philosophies before getting comfortable :) The array type syntax you quoted is a bit like Haskell's `[Char]` syntax with a fixed-length property bolted on. You are right, though, that semicolon looks a bit weird. I guess using commas was not an option because the same syntax on the right hand side of the `=` means `[0, 0]`, i.e. two elements which are 0.
frewsxcv 12y ago
[0; 2] and [0, 2] are both valid in Rust, but mean different things. http://doc.rust-lang.org/reference.html#array-expressions http://doc.rust-lang.org/reference.html#array-expressions I suggest learning the language before making an attempt to criticize it.
- ivoras 12y ago
  > I suggest learning the language before making an attempt to criticize it. I will learn it. I like the semantics of Rust, it's a thing which needed to be attempted. What I am suggesting is, that for a language to be popular and accepted in already existing communities, it should have as little syntactic differences from the standards already present in those communities (or more elaborate: that things with similar semantics should have similar syntax). This does not preclude adding both new semantics and new syntax to the language. In this case, I think the "target audience" for Rust is the crowd already familiar with C and C++, and languages (which are in many cases superior to C and C++) with significant differences such as LISP, Haskell, Erlang are vastly less popular compared to C, C++, C#, Java, JavaScript. As a counter-example to my claim I recognize Python, which succeeded even if it was radically different and even today has some serious issues (for me, it is its performance and the GIL in CPython). IMO, it succeeded precisely because it was radically different than mainstream languages before it, so it didn't cause "mind crosstalk" issues you get when you encounter something which seems familiar but actually isn't. Of course, this is inconsequential, it really boils down to arguing about personal taste and preferences. And even if I am right, if the semantics of Rust become popular, I'm sure that a more C-like language will evolve from it (maybe called Crust? :D ). If I am wrong, Rust will live long and prosper as it is.
  - kyllo 12y ago
    The syntax itself is such a low hurdle to learning the language it hardly merits complaining about, especially given how drastically the Rust core team has simplified the syntax of the language since its early days. It's not particularly arcane at all if you've ever used C/C++, Ruby, and perhaps any ML-family language (SML, OCaml, Haskell, F#) because Rust cherry-picks the best ideas from each of those languages. Go is intended to be syntactically very C-like, you may find it more comfortable than Rust in that regard.
Jweb_Guru 12y ago
The semicolon decision was equally baffling to a lot of longtime Rust users, as previously , .. was used (or possibly , ...? I honestly can't remember). It was changed because with Rust's new range syntax x..y, there was a conflict in the grammar, at least that's my recollection. Anyway, my experience with stuff like this is that they're horribly confusing for a couple of days and then you forget (as you can see, I already don't remember the old grammar).
scott_s 12y ago
Because familiar is not necessarily good. After many decades of use, we have realized that C has many suboptimal syntax decisions.
- saosebastiao 12y ago
  And yet the decision to keep <> as the type annotation container was made entirely on the basis of familiarity, despite the fact that most people in the discussion personally preferred the more intuitive and readable but unfamiliar syntax inspiration from D or Scala. They didn't want to alienate the C++ crowd. There are lots of competing ideologies about syntax in the rust community. Not everybody thinks the same way.
  - steveklabnik 12y ago
    > was made entirely on the basis of familiarity, This is sorta kinda true. A long time ago, Rust used `[]`s. Then, at some point, it changed to `<>`s. When the discussion you're referring to came up, it was determined that there wasn't a good enough reason to switch back to `[]`s, as that also introduced other problems, and so wasn't clearly better, and would introduce a lot of churn.
    - frowaway001 12y ago
      I'd love to know which problems that would have introduced. Rust's choice of <> ignored the lessons from all the language which made that choice before (Java, C#, C++) and from there, other bad ideas just snowballed on top of it.
      - steveklabnik 12y ago
        Since it's also used for array access, it introduces another ambiguity in the grammar there.
        saosebastiao 12y ago
pcwalton 12y ago
> Why not declare the array type as c_int[2]? Because the "&" reference operator goes before types, not after. (Rust makes the same decision as, for example, Go does.) This would lead to ambiguity when combined with postfix array type notation. What does "&c_int[2]" mean: is it "(&c_int)[2]" or "&(c_int[2])"?

by ivoras 12y ago

vertex-four 12y ago

> Why not declare the array type as c_int[2]? Because a design decision was made that the type should look like the instantiation of that type. Same with structs and enums. > And why use semicolons instead of commas? Because this is "two elements both containing 0", not the array [0, 2]. Semicolons are used for that.

killercup 12y ago

> if the reader is familiar with other C-like languages I like to think that Rust wants you to be familiar with C and ML syntax and philosophies before getting comfortable :) The array type syntax you quoted is a bit like Haskell's `[Char]` syntax with a fixed-length property bolted on. You are right, though, that semicolon looks a bit weird. I guess using commas was not an option because the same syntax on the right hand side of the `=` means `[0, 0]`, i.e. two elements which are 0.

frewsxcv 12y ago

[0; 2] and [0, 2] are both valid in Rust, but mean different things. http://doc.rust-lang.org/reference.html#array-expressions http://doc.rust-lang.org/reference.html#array-expressions I suggest learning the language before making an attempt to criticize it.

ivoras 12y ago
> I suggest learning the language before making an attempt to criticize it. I will learn it. I like the semantics of Rust, it's a thing which needed to be attempted. What I am suggesting is, that for a language to be popular and accepted in already existing communities, it should have as little syntactic differences from the standards already present in those communities (or more elaborate: that things with similar semantics should have similar syntax). This does not preclude adding both new semantics and new syntax to the language. In this case, I think the "target audience" for Rust is the crowd already familiar with C and C++, and languages (which are in many cases superior to C and C++) with significant differences such as LISP, Haskell, Erlang are vastly less popular compared to C, C++, C#, Java, JavaScript. As a counter-example to my claim I recognize Python, which succeeded even if it was radically different and even today has some serious issues (for me, it is its performance and the GIL in CPython). IMO, it succeeded precisely because it was radically different than mainstream languages before it, so it didn't cause "mind crosstalk" issues you get when you encounter something which seems familiar but actually isn't. Of course, this is inconsequential, it really boils down to arguing about personal taste and preferences. And even if I am right, if the semantics of Rust become popular, I'm sure that a more C-like language will evolve from it (maybe called Crust? :D ). If I am wrong, Rust will live long and prosper as it is.
- kyllo 12y ago
  The syntax itself is such a low hurdle to learning the language it hardly merits complaining about, especially given how drastically the Rust core team has simplified the syntax of the language since its early days. It's not particularly arcane at all if you've ever used C/C++, Ruby, and perhaps any ML-family language (SML, OCaml, Haskell, F#) because Rust cherry-picks the best ideas from each of those languages. Go is intended to be syntactically very C-like, you may find it more comfortable than Rust in that regard.

Jweb_Guru 12y ago

The semicolon decision was equally baffling to a lot of longtime Rust users, as previously , .. was used (or possibly , ...? I honestly can't remember). It was changed because with Rust's new range syntax x..y, there was a conflict in the grammar, at least that's my recollection. Anyway, my experience with stuff like this is that they're horribly confusing for a couple of days and then you forget (as you can see, I already don't remember the old grammar).

scott_s 12y ago

Because familiar is not necessarily good. After many decades of use, we have realized that C has many suboptimal syntax decisions.

saosebastiao 12y ago
And yet the decision to keep <> as the type annotation container was made entirely on the basis of familiarity, despite the fact that most people in the discussion personally preferred the more intuitive and readable but unfamiliar syntax inspiration from D or Scala. They didn't want to alienate the C++ crowd. There are lots of competing ideologies about syntax in the rust community. Not everybody thinks the same way.
- steveklabnik 12y ago
  > was made entirely on the basis of familiarity, This is sorta kinda true. A long time ago, Rust used `[]`s. Then, at some point, it changed to `<>`s. When the discussion you're referring to came up, it was determined that there wasn't a good enough reason to switch back to `[]`s, as that also introduced other problems, and so wasn't clearly better, and would introduce a lot of churn.
  - frowaway001 12y ago
    I'd love to know which problems that would have introduced. Rust's choice of <> ignored the lessons from all the language which made that choice before (Java, C#, C++) and from there, other bad ideas just snowballed on top of it.
    - steveklabnik 12y ago
      Since it's also used for array access, it introduces another ambiguity in the grammar there.
      - saosebastiao 12y ago

pcwalton 12y ago

> Why not declare the array type as c_int[2]? Because the "&" reference operator goes before types, not after. (Rust makes the same decision as, for example, Go does.) This would lead to ambiguity when combined with postfix array type notation. What does "&c_int[2]" mean: is it "(&c_int)[2]" or "&(c_int[2])"?