4 ms·

My favorite part of Rust. Please just leave it as is ;)

berkes 6y ago
My thought too, was 'my favorite part of Rust'. But the second thought was 'I'm excited to see it becoming even better'.
- mojzu 6y ago
  They've definitely earned some credit in my eyes for the async/await syntax. There was quite a bit of pushback for deviating from the norm there, but after using it for a few months other languages async/await just feels clunky to me now. Rust error handling is the best I've used but if there's a way to make it better then I'm up for it.
  - Qwuke 6y ago
    As someone who was on the fence about it, I feel exactly the same. The way the Rust maintainers and proponents of post-fix await helped create broader community consensus was impressive in itself too.
    - octoberfranklin 6y ago
      I think that compromise was brilliant, by the way. The only other C-family language with that syntax (dot followed by keyword) I know of is Java (where you can write foobarbaz.class; "class" is a language keyword) and it always looked weird. The Rust maintainers found a great use for it: getting chaining (foo.await?.bar()?.await...) without adding a new postfix "sigil".
octoberfranklin 6y ago
... only after they ship try_blocks! https://doc.rust-lang.org/nightly/unstable-book/language-features/try-blocks.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... Seriously, otherwise you can't do error handling within the body of a function that doesn't return Result<>. The language shouldn't force refactoring decisions on the programmer like that.
- zozbot234 6y ago
  > Seriously, otherwise you can't do error handling within the body of a function that doesn't return Result<>. Sure you can, just use an inner closure that does return Result<>, and use `match` or the like for error handling. It's not any more verbose than this `try {} ... catch {}` special syntax.
  - octoberfranklin 6y ago
    > It's not any more verbose Seriously? I think this is way less readable: (|| -> Result<_,_> { bar(foo()?) })() than this: try { bar(foo()?)? } Also try_blocks don't have to have a "catch". It's just five characters: "t" "r" "y" "{" "}". I don't see a need for "catch" either.
    - Arnavion 6y ago
      The closure version would actually be (|| -> Result<_,_> { Ok(bar(foo()?)?) })() to be equivalent, since bar's Err type might need a From::from conversion via `?`. So the try-blocks version is even better in comparison. That said, if you include the `-> Result<_,_>` annotation in the closure case, you also need to include the `: Result<_,_>` annotation for the binding that the try-expr is being assigned to, otherwise the compiler won't know which impl of `std::ops::Try` to use. Of course, you can also use an annotation on the binding in the closure case and get rid of the annotation entirely. That is, the comparison is of: let r: Result<_, _> = (|| Ok(bar(foo()?)?))(); vs let r: Result<_, _> = try { bar(foo()?)? };
      - octoberfranklin 6y ago
        I still find the second case far more readable. When you see "try{}" it says "this is here because I want to turn on ?-handling within this block". When you see a closure formed and then immediately applied it says... well I dunno. Frankly it seems to say "this expression should be simplifiable". In fact it's a huge wart on Rust that beta-reduction doesn't preserve well-formedness of expressions. Also if there were more stuff in the expression body it might not even be obvious at a glance that the closure is being formed-and-then-immediately-invoked, leading a reviewer to wonder "wtf is a closure doing here?".

My thought too, was 'my favorite part of Rust'. But the second thought was 'I'm excited to see it becoming even better'.

mojzu 6y ago
They've definitely earned some credit in my eyes for the async/await syntax. There was quite a bit of pushback for deviating from the norm there, but after using it for a few months other languages async/await just feels clunky to me now. Rust error handling is the best I've used but if there's a way to make it better then I'm up for it.
- Qwuke 6y ago
  As someone who was on the fence about it, I feel exactly the same. The way the Rust maintainers and proponents of post-fix await helped create broader community consensus was impressive in itself too.
  - octoberfranklin 6y ago
    I think that compromise was brilliant, by the way. The only other C-family language with that syntax (dot followed by keyword) I know of is Java (where you can write foobarbaz.class; "class" is a language keyword) and it always looked weird. The Rust maintainers found a great use for it: getting chaining (foo.await?.bar()?.await...) without adding a new postfix "sigil".

octoberfranklin 6y ago

... only after they ship try_blocks! https://doc.rust-lang.org/nightly/unstable-book/language-features/try-blocks.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... Seriously, otherwise you can't do error handling within the body of a function that doesn't return Result<>. The language shouldn't force refactoring decisions on the programmer like that.

zozbot234 6y ago
> Seriously, otherwise you can't do error handling within the body of a function that doesn't return Result<>. Sure you can, just use an inner closure that does return Result<>, and use `match` or the like for error handling. It's not any more verbose than this `try {} ... catch {}` special syntax.
- octoberfranklin 6y ago
  > It's not any more verbose Seriously? I think this is way less readable: (|| -> Result<_,_> { bar(foo()?) })() than this: try { bar(foo()?)? } Also try_blocks don't have to have a "catch". It's just five characters: "t" "r" "y" "{" "}". I don't see a need for "catch" either.
  - Arnavion 6y ago
    The closure version would actually be (|| -> Result<_,_> { Ok(bar(foo()?)?) })() to be equivalent, since bar's Err type might need a From::from conversion via `?`. So the try-blocks version is even better in comparison. That said, if you include the `-> Result<_,_>` annotation in the closure case, you also need to include the `: Result<_,_>` annotation for the binding that the try-expr is being assigned to, otherwise the compiler won't know which impl of `std::ops::Try` to use. Of course, you can also use an annotation on the binding in the closure case and get rid of the annotation entirely. That is, the comparison is of: let r: Result<_, _> = (|| Ok(bar(foo()?)?))(); vs let r: Result<_, _> = try { bar(foo()?)? };
    - octoberfranklin 6y ago
      I still find the second case far more readable. When you see "try{}" it says "this is here because I want to turn on ?-handling within this block". When you see a closure formed and then immediately applied it says... well I dunno. Frankly it seems to say "this expression should be simplifiable". In fact it's a huge wart on Rust that beta-reduction doesn't preserve well-formedness of expressions. Also if there were more stuff in the expression body it might not even be obvious at a glance that the closure is being formed-and-then-immediately-invoked, leading a reviewer to wonder "wtf is a closure doing here?".