5 ms·

The learning curve was far worse than I expected This has been true for me as well. Rust seems to have gratuitous syntax. If C did something and there was anot

The learning curve was far worse than I expected This has been true for me as well. Rust seems to have gratuitous syntax. If C did something and there was another way to do it then that other way was chosen. With C if you want to return the value 42 then you say return 42; With Rust you say 42. There is a return statement; it just can't return anything. If you say if (a == b) Rust says: warning: unnecessary parentheses around `if` condition I'm willing to put up with this nonsense because of the safety guarantees. But really, it reminds me of Bananas: In addition to that, all citizens will be required to change their underwear every half hour. Underwear will be worn on the outside so we can check. Edit: I got this a little but not a lot wrong. return 42 is supported but then it isn't clear at all why 42 is necessary. So my complaint of gratuitous syntax stands as does my respect for Rust's safety guarantees.

steveklabnik 10y ago
> With Rust you say 42. This is, strictly speaking, not true. Rust is an "everything[1] is an expression language", and so if you have some sort of block, it will evaluate to its last expression. But if you want to do an early return, you must write it, or if you don't like the default Rust style, you can write it. This is consistent with other languages, just not C. 1: not literally everything, but most things.
- CalChris 10y ago
  > This is consistent with other languages, just not C. TIOBE Index January 2017. The top 10 languages are Java, C, C++, Python, Visual Basic, Javascript, Perl, Assembly, PHP Except for Assembly, where the comparison makes no sense, all of these languages have return expression. Yes, there are other languages that use last expression but they are most definitely not common languages and the most common languages use return expression. It just seems unnecessary. It isn't clear what they got out of it.
  - GFK_of_xmaspast 10y ago
    Perl has implicit return.
  - Manishearth 10y ago
    Ruby has a similar pattern. It's a pretty popular language. Correlation is not causation. Having return expressions does not make or break a language. Python and JS do have return expressions in the context of lambdas. I'm not very fond of this pattern in untyped languages (Ruby, Perl) because it can lead to accidental returns, but I'm pretty happy with having it in a typed language.
  - serge2k 10y ago
    You can do some very nice things with that sort of syntax. Being able to assign values based on an if statement is one example that just makes life a little better. Just a tiny bit. :)
  - lobster_johnson 10y ago
    JavaScript supports implicit return in anonymous functions: let lowercased = names.map(name => name.toLowerCase());
  - flukus 10y ago
    The thing all those languages have in common is mutability by default. Being able to return values from if/else eliminates a lot of variables that would need to be mutable otherwise.
Ralith 10y ago
> There is a return statement; it just can't return anything What? Return works exactly like it does in C, it's just not required as much. > warning: unnecessary parentheses around `if` condition I'm confused about how reducing the amount of required syntax is "gratuitous syntax."
Manishearth 10y ago
Be aware that there are plenty of languages out there that have these same syntax decisions. Rust did not choose things because it wanted to "not look like C", if anything Rust has tried to keep its syntax roughly C-like with braces and stuff to not be too surprising. Rust avoids parentheses in if conditions because Rust enforces braces in if bodies -- you only need one or the other for parsing to work. C chooses the opposite decision, and C has plenty of problems with omitting braces. Also, `42` will only return at the end of a block. It's different, but not a magical return that can be placed anywhere. The return statement works exactly like C. "Rust's syntax is different from C" is perhaps the mildest criticism I can think of Rust. Thank you.
- fjrieiekd 10y ago
  In fairness, it's harder to learn Rust as one has to be aware of when and when not to put semi-colons, otherwise the compiler chokes with an unhelpful error. It also looks very weird to see a trailing value just hanging at the end of a long function. I much prefer the decisions Swift made in this area, with no semicolons and implicit returns only for short functions. This isn't to knock Rust or the work that you guys do, just a part of the language that can be learned, but does impose a speed bump during that learning process.
  - Manishearth 10y ago
    I mean, yeah, but you can say the exact same thing about braces in C. Rust lets you use explicit return all the time (with semicolons everywhere), if you want to. C lets you use explicit braces all the time, if you want to. Rust also lets you use expression returns by omitting semicolons, which is a common programming style. C also lets you omit braces, which is a common programming style. Being common programming styles, you have to deal with them often. Both are a bit confusing to wrap your head around at first. I find that Rust's confusingness is fine because you can't goof up with it; the compiler will error if you do. C on the other hand will happily let you mess up your braces and still compile. Again, this is different, not worse.
GFK_of_xmaspast 10y ago
> There is a return statement; it just can't return anything There are lots of languages out there that have implicit return, such as scala and ocaml and f#.
dj-wonk 10y ago
Your examples are glossed over too quickly. So far, I'm trying to see what you are saying, but I don't get it. In short, I'm open to being convinced, but you aren't making your points convincingly. Want to make a detailed list of your so-called "gratuitous" syntax and invite discussion, point by point, in an open-minded way? If there is a simpler syntactic way to capture the semantics and design goals of Rust, I think people would be open to hearing it. I don't think you'll feel the same way after you invite discussion around it.
serge2k 10y ago
These are just minor syntax complaints though. You get used to it, and start to appreciate some of this stuff quickly IMO. I spent far too much time trying to figure out how to use string and str. That's where it becomes absurd. I'm fine with fighting with the type/memory systems a bit, but when something that seems simple becomes a confusing mess it's just frustration.
- steveklabnik 10y ago
  The second edition of the book uses String and &str to explain ownership and borrowing, since this is a common pitfall: http://rust-lang.github.io/book/ch04-00-understanding-ownership.html http://rust-lang.github.io/book/ch04-00-understanding-owners...
tatterdemalion 10y ago
> I got this a little but not a lot wrong. return 42 is supported but then it isn't clear at all why 42 is necessary. The reason this is very good is closures, which have the same return semantics as functions, are often a single expression, and are most useful to fit on one line. `.filter(|x| x.foo_bar() < some_other.foo_bar())`. Removing the return statement helps here. Its a behavior shared with many (but not all) languages that make heavy use of anonymous functions.
- fjrieiekd 10y ago
  Swift does support this also, but they limited it so they could also get rid of semicolons entirely.
sinistersnare 10y ago
You can say `return 42;` and it will return 42 as expected. Rust doesn't require parens in an if expression because it requires brackets. You could silence the warning and use parens though.

steveklabnik 10y ago

> With Rust you say 42. This is, strictly speaking, not true. Rust is an "everything[1] is an expression language", and so if you have some sort of block, it will evaluate to its last expression. But if you want to do an early return, you must write it, or if you don't like the default Rust style, you can write it. This is consistent with other languages, just not C. 1: not literally everything, but most things.

CalChris 10y ago
> This is consistent with other languages, just not C. TIOBE Index January 2017. The top 10 languages are Java, C, C++, Python, Visual Basic, Javascript, Perl, Assembly, PHP Except for Assembly, where the comparison makes no sense, all of these languages have return expression. Yes, there are other languages that use last expression but they are most definitely not common languages and the most common languages use return expression. It just seems unnecessary. It isn't clear what they got out of it.
- GFK_of_xmaspast 10y ago
  Perl has implicit return.
- Manishearth 10y ago
  Ruby has a similar pattern. It's a pretty popular language. Correlation is not causation. Having return expressions does not make or break a language. Python and JS do have return expressions in the context of lambdas. I'm not very fond of this pattern in untyped languages (Ruby, Perl) because it can lead to accidental returns, but I'm pretty happy with having it in a typed language.
- serge2k 10y ago
  You can do some very nice things with that sort of syntax. Being able to assign values based on an if statement is one example that just makes life a little better. Just a tiny bit. :)
- lobster_johnson 10y ago
  JavaScript supports implicit return in anonymous functions: let lowercased = names.map(name => name.toLowerCase());
- flukus 10y ago
  The thing all those languages have in common is mutability by default. Being able to return values from if/else eliminates a lot of variables that would need to be mutable otherwise.

Ralith 10y ago

> There is a return statement; it just can't return anything What? Return works exactly like it does in C, it's just not required as much. > warning: unnecessary parentheses around `if` condition I'm confused about how reducing the amount of required syntax is "gratuitous syntax."

Manishearth 10y ago

Be aware that there are plenty of languages out there that have these same syntax decisions. Rust did not choose things because it wanted to "not look like C", if anything Rust has tried to keep its syntax roughly C-like with braces and stuff to not be too surprising. Rust avoids parentheses in if conditions because Rust enforces braces in if bodies -- you only need one or the other for parsing to work. C chooses the opposite decision, and C has plenty of problems with omitting braces. Also, `42` will only return at the end of a block. It's different, but not a magical return that can be placed anywhere. The return statement works exactly like C. "Rust's syntax is different from C" is perhaps the mildest criticism I can think of Rust. Thank you.

fjrieiekd 10y ago
In fairness, it's harder to learn Rust as one has to be aware of when and when not to put semi-colons, otherwise the compiler chokes with an unhelpful error. It also looks very weird to see a trailing value just hanging at the end of a long function. I much prefer the decisions Swift made in this area, with no semicolons and implicit returns only for short functions. This isn't to knock Rust or the work that you guys do, just a part of the language that can be learned, but does impose a speed bump during that learning process.
- Manishearth 10y ago
  I mean, yeah, but you can say the exact same thing about braces in C. Rust lets you use explicit return all the time (with semicolons everywhere), if you want to. C lets you use explicit braces all the time, if you want to. Rust also lets you use expression returns by omitting semicolons, which is a common programming style. C also lets you omit braces, which is a common programming style. Being common programming styles, you have to deal with them often. Both are a bit confusing to wrap your head around at first. I find that Rust's confusingness is fine because you can't goof up with it; the compiler will error if you do. C on the other hand will happily let you mess up your braces and still compile. Again, this is different, not worse.

GFK_of_xmaspast 10y ago

> There is a return statement; it just can't return anything There are lots of languages out there that have implicit return, such as scala and ocaml and f#.

dj-wonk 10y ago

Your examples are glossed over too quickly. So far, I'm trying to see what you are saying, but I don't get it. In short, I'm open to being convinced, but you aren't making your points convincingly. Want to make a detailed list of your so-called "gratuitous" syntax and invite discussion, point by point, in an open-minded way? If there is a simpler syntactic way to capture the semantics and design goals of Rust, I think people would be open to hearing it. I don't think you'll feel the same way after you invite discussion around it.

serge2k 10y ago

These are just minor syntax complaints though. You get used to it, and start to appreciate some of this stuff quickly IMO. I spent far too much time trying to figure out how to use string and str. That's where it becomes absurd. I'm fine with fighting with the type/memory systems a bit, but when something that seems simple becomes a confusing mess it's just frustration.

steveklabnik 10y ago
The second edition of the book uses String and &str to explain ownership and borrowing, since this is a common pitfall: http://rust-lang.github.io/book/ch04-00-understanding-ownership.html http://rust-lang.github.io/book/ch04-00-understanding-owners...

tatterdemalion 10y ago

> I got this a little but not a lot wrong. return 42 is supported but then it isn't clear at all why 42 is necessary. The reason this is very good is closures, which have the same return semantics as functions, are often a single expression, and are most useful to fit on one line. `.filter(|x| x.foo_bar() < some_other.foo_bar())`. Removing the return statement helps here. Its a behavior shared with many (but not all) languages that make heavy use of anonymous functions.

fjrieiekd 10y ago
Swift does support this also, but they limited it so they could also get rid of semicolons entirely.

sinistersnare 10y ago

You can say `return 42;` and it will return 42 as expected. Rust doesn't require parens in an if expression because it requires brackets. You could silence the warning and use parens though.