6 ms·

Though I like ideas behind Rust but the code is awful. If you look at the code you'll see a lot of misterious symbols (as in Perl) and strange constructs like w

Though I like ideas behind Rust but the code is awful. If you look at the code you'll see a lot of misterious symbols (as in Perl) and strange constructs like wrap, unwrap, Arc etc. They make the code less readable. Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. I looked at one random file which turned out to be a `du' command implementation: https://github.com/uutils/coreutils/blob/master/src/du/du.rs#L89 https://github.com/uutils/coreutils/blob/master/src/du/du.rs... Are they really starting a new OS level thread for every directory found? Looks like an easy way to exhaust system resources to me. Also I don't see the code that would collect error information if if the thread panics.

0xFFC 11y ago
>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need simple thing to do, but rust designed to do low-level stuff, and I cannot understand how having not having exception makes a language ugly (specially when you code in lowlevel).
- bigdubs 11y ago
  Comment OP's stance is valid. "Magic" in this context are keywords or symbols that are not immediately clear to programmers that don't work in rust. One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). FWIW I also share their opinion that rust is unapproachable.
  - codedokode 11y ago
    Golang has some magic too - for example magic with capital letters in exported symbols. But generally golang is easier to read than line like this: > static NAME: &'static str = "du";
    - pcwalton 11y ago
      Because Rust has lifetimes and Go doesn't, so Go doesn't need syntax for them. If you want to argue that Rust should use a garbage collector like Golang does (which entails arguing that everybody who is using Rust is wrong for not wanting an always-on GC) I'm happy to have that argument, but say so explicitly.
  - dang 11y ago
    > keywords or symbols that are not immediately clear to programmers that don't work in rust That's an argument against introducing new notation for anything. That can't be right.
  - pcwalton 11y ago
    > One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). Do you have a specific symbol you would like to change in Rust, and what would you like to change it to? The only example I've seen (in a child comment to yours) is effectively a complaint that Rust has lifetimes and Go doesn't, which is effectively saying "you should have a garbage collector like Go does", which is an argument against a fundamental design decision of Rust. If you want to argue that you should always use a garbage collector, argue that directly instead of making vague negative comparisons between Rust's and Go's syntax.
    - dikaiosune 11y ago
      I'm definitely a Rust fanboy, but the single-quote syntax for lifetime annotations can be irritating. Several editors I've used automatically insert a second quote to match, and I am frequently unable to disable that behavior without losing all paired delimiter insertion (like for parentheses or braces). It's a minor quibble to be sure, but it's the only language symbol that bothers me when writing Rust. Not sure what I'd suggest replacing it with...backtick, maybe? Pipe? @? ~? There aren't many other special characters on a QWERTY board that aren't already used in Rust. Which I think gets at one of the stumbling blocks that I see in the various Rust syntax bikesheds among those who haven't worked in the language. It's just alien until you've used it a bit, especially if you're writing a lot in pseudocode-y dynamic languages.
      - wting 11y ago
        Rust used to have @ and ~ sigils* but they were removed for legibility reasons and difficulty typing on European keyboards. * For heap and owner pointers respectively.
      - pcwalton 11y ago
        We had a big debate about it back in the day, and ' won as it's about as visually lightweight as you can get. I think the other characters you suggested would invite even more Perl comparisons.
- codedokode 11y ago
  I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.
  - TheCoelacanth 11y ago
    try! macro results in code that looks pretty similar to exceptions: https://doc.rust-lang.org/std/macro.try!.html https://doc.rust-lang.org/std/macro.try!.html
  - masklinn 11y ago
    > I mean if you have to write that match construct around every function call Not quite. 1. you're supposed to handle errors around function calls which can fail, which is a strict subset of "every function call" 2. rust has a number of higher-order constructs to facilitate that handling[0][1][2], not just raw `match` statements or expressions. That aside, for rust explicit error handling is considered a feature both at the language level (allows for less runtime requirements and much stronger guarantees — check out exception-safe C++ for what happens when low-level meets exceptions) and at the user level (by forcing a conscious and explicit decision, whether it's crashing the system, handling the error or passing the ball upwards) > the code quickly gets bloated, doesn't it? Does C code quickly get bloated? Because you're also supposed to check for error codes after each function call which can fail, and C doesn't provide much abstractive power to mitigate that. [0] http://doc.rust-lang.org/std/result/enum.Result.html http://doc.rust-lang.org/std/result/enum.Result.html [1] http://doc.rust-lang.org/core/macro.try!.html http://doc.rust-lang.org/core/macro.try!.html [2] https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243
  - habitue 11y ago
    Rust has macros, so boilerplate can be swept up pretty tidily. In the case of propagating up errors, there is the try! macro that encapsulates a match that returns early with the error
  - tmerr 11y ago
    Yeah Error handling bloat is a problem. You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err") You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing. This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.
freekh 11y ago
Just wrt the let/match/Ok/Err == ugly comment: I don't know Rust very well and I haven't looked very closely at the code in question, but why would Rust force you to wrap almost any function call with let/match/Ok/Err, though? I am assuming the issue at hand here is when you call function that returns a Result (if that's the name of the parent of Ok/Err)? Couldn't one let the return values 'flow up'? For example: if a function starts returning Results and you don't handle it on the level above, you start returning Results too... Also, I suppose there's ways of flattening results to avoid having nested Results (I would guess and_then does that based on its signature?)? In this scenario, you could argue that one now replaces match with map at every function call where you do not actually handle the Err and that this is ugly too, but the alternative is hoping that the caller happens to have read your source code (or have checked exceptions), which is, arguably (to be diplomatic), the case for unchecked-exceptions. Then what happens if you change the code and so on and so on... This way lets you achieve something similar to checked-exceptions, and in addition to gain composability of Err (and the like), without adding another language construct (which a language without exceptions would have to do). Got a great deal of experience in other languages that does this, and it's worked out pretty good so far for at least for me once you get the hang of it (i.e. functional coding). Where I am sitting, that would be a wise choice for Rust, at least if I am understanding it correctly, as it tries to be a safer alternative to other system languages. However, arguably (:), it is OK in dynamic languages or similar that aims trades in correctness for conciseness and, arguable (again :), speed of development to simply have unchecked-exceptions. Also, it is possible I misunderstood your comment and/or how that code was ugly, in which case I hope the downvotes/replies won't be too harsh :) EDIT: typo/clarity
- paulddraper 11y ago
  Yes Rust lets you flatten the results.
- onaplane 11y ago
  Yeah, codedokode is wrong. Rust lets you keep returning Results as you described. You don't even need to actually write a match statement yourself: there's a built in try! macro, which will do an early return from a function if a function call returns an Err value. And soon there will be a new ? operator which does this inline so you don't even need the macro. What you end up with are much more flexible "exceptions" that don't need a lot of extra compiler support.
pcwalton 11y ago
There aren't any mysterious symbols left in Rust that aren't in C++. Can you name one? The Perl comparison doesn't make sense to me. Also, idiomatic code doesn't match on errors; it uses try!. And nightly now supports a ? syntax that's even shorter.

0xFFC 11y ago

>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need simple thing to do, but rust designed to do low-level stuff, and I cannot understand how having not having exception makes a language ugly (specially when you code in lowlevel).

bigdubs 11y ago
Comment OP's stance is valid. "Magic" in this context are keywords or symbols that are not immediately clear to programmers that don't work in rust. One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). FWIW I also share their opinion that rust is unapproachable.
- codedokode 11y ago
  Golang has some magic too - for example magic with capital letters in exported symbols. But generally golang is easier to read than line like this: > static NAME: &'static str = "du";
  - pcwalton 11y ago
    Because Rust has lifetimes and Go doesn't, so Go doesn't need syntax for them. If you want to argue that Rust should use a garbage collector like Golang does (which entails arguing that everybody who is using Rust is wrong for not wanting an always-on GC) I'm happy to have that argument, but say so explicitly.
- dang 11y ago
  > keywords or symbols that are not immediately clear to programmers that don't work in rust That's an argument against introducing new notation for anything. That can't be right.
- pcwalton 11y ago
  > One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). Do you have a specific symbol you would like to change in Rust, and what would you like to change it to? The only example I've seen (in a child comment to yours) is effectively a complaint that Rust has lifetimes and Go doesn't, which is effectively saying "you should have a garbage collector like Go does", which is an argument against a fundamental design decision of Rust. If you want to argue that you should always use a garbage collector, argue that directly instead of making vague negative comparisons between Rust's and Go's syntax.
  - dikaiosune 11y ago
    I'm definitely a Rust fanboy, but the single-quote syntax for lifetime annotations can be irritating. Several editors I've used automatically insert a second quote to match, and I am frequently unable to disable that behavior without losing all paired delimiter insertion (like for parentheses or braces). It's a minor quibble to be sure, but it's the only language symbol that bothers me when writing Rust. Not sure what I'd suggest replacing it with...backtick, maybe? Pipe? @? ~? There aren't many other special characters on a QWERTY board that aren't already used in Rust. Which I think gets at one of the stumbling blocks that I see in the various Rust syntax bikesheds among those who haven't worked in the language. It's just alien until you've used it a bit, especially if you're writing a lot in pseudocode-y dynamic languages.
    - wting 11y ago
      Rust used to have @ and ~ sigils* but they were removed for legibility reasons and difficulty typing on European keyboards. * For heap and owner pointers respectively.
    - pcwalton 11y ago
      We had a big debate about it back in the day, and ' won as it's about as visually lightweight as you can get. I think the other characters you suggested would invite even more Perl comparisons.
codedokode 11y ago
I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.
- TheCoelacanth 11y ago
  try! macro results in code that looks pretty similar to exceptions: https://doc.rust-lang.org/std/macro.try!.html https://doc.rust-lang.org/std/macro.try!.html
- masklinn 11y ago
  > I mean if you have to write that match construct around every function call Not quite. 1. you're supposed to handle errors around function calls which can fail, which is a strict subset of "every function call" 2. rust has a number of higher-order constructs to facilitate that handling[0][1][2], not just raw `match` statements or expressions. That aside, for rust explicit error handling is considered a feature both at the language level (allows for less runtime requirements and much stronger guarantees — check out exception-safe C++ for what happens when low-level meets exceptions) and at the user level (by forcing a conscious and explicit decision, whether it's crashing the system, handling the error or passing the ball upwards) > the code quickly gets bloated, doesn't it? Does C code quickly get bloated? Because you're also supposed to check for error codes after each function call which can fail, and C doesn't provide much abstractive power to mitigate that. [0] http://doc.rust-lang.org/std/result/enum.Result.html http://doc.rust-lang.org/std/result/enum.Result.html [1] http://doc.rust-lang.org/core/macro.try!.html http://doc.rust-lang.org/core/macro.try!.html [2] https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243
- habitue 11y ago
  Rust has macros, so boilerplate can be swept up pretty tidily. In the case of propagating up errors, there is the try! macro that encapsulates a match that returns early with the error
- tmerr 11y ago
  Yeah Error handling bloat is a problem. You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err") You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing. This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.

freekh 11y ago

Just wrt the let/match/Ok/Err == ugly comment: I don't know Rust very well and I haven't looked very closely at the code in question, but why would Rust force you to wrap almost any function call with let/match/Ok/Err, though? I am assuming the issue at hand here is when you call function that returns a Result (if that's the name of the parent of Ok/Err)? Couldn't one let the return values 'flow up'? For example: if a function starts returning Results and you don't handle it on the level above, you start returning Results too... Also, I suppose there's ways of flattening results to avoid having nested Results (I would guess and_then does that based on its signature?)? In this scenario, you could argue that one now replaces match with map at every function call where you do not actually handle the Err and that this is ugly too, but the alternative is hoping that the caller happens to have read your source code (or have checked exceptions), which is, arguably (to be diplomatic), the case for unchecked-exceptions. Then what happens if you change the code and so on and so on... This way lets you achieve something similar to checked-exceptions, and in addition to gain composability of Err (and the like), without adding another language construct (which a language without exceptions would have to do). Got a great deal of experience in other languages that does this, and it's worked out pretty good so far for at least for me once you get the hang of it (i.e. functional coding). Where I am sitting, that would be a wise choice for Rust, at least if I am understanding it correctly, as it tries to be a safer alternative to other system languages. However, arguably (:), it is OK in dynamic languages or similar that aims trades in correctness for conciseness and, arguable (again :), speed of development to simply have unchecked-exceptions. Also, it is possible I misunderstood your comment and/or how that code was ugly, in which case I hope the downvotes/replies won't be too harsh :) EDIT: typo/clarity

paulddraper 11y ago
Yes Rust lets you flatten the results.
onaplane 11y ago
Yeah, codedokode is wrong. Rust lets you keep returning Results as you described. You don't even need to actually write a match statement yourself: there's a built in try! macro, which will do an early return from a function if a function call returns an Err value. And soon there will be a new ? operator which does this inline so you don't even need the macro. What you end up with are much more flexible "exceptions" that don't need a lot of extra compiler support.

pcwalton 11y ago

There aren't any mysterious symbols left in Rust that aren't in C++. Can you name one? The Perl comparison doesn't make sense to me. Also, idiomatic code doesn't match on errors; it uses try!. And nightly now supports a ? syntax that's even shorter.