3 ms·

There has been some uh, lively discussion about this post on various reddits since yesterday. The author said > I wanted to try writing the article in an infl

There has been some uh, lively discussion about this post on various reddits since yesterday. The author said > I wanted to try writing the article in an inflammatory style for engagement. but to respond to some of the things claimed, for anyone curious: > Just give me a garbage collector, and let me do what I want to do! This is absolutely a reasonable opinion to have, but it means Rust was just not the correct choice. That doesn't mean Rust is bad. > Maybe I’m just an idiot and can’t figure out how to enable stack traces. But when an error happens in my application, I have no idea why! Panics have an environment variable you can set to print a stacktrace. You can also grab a stacktrace yourself with the tools in std::backtrace, and many error libraries like anyhow will let you capture backtraces for Results. However, part of the pain the author is feeling here is that instead of using error objects directly, their example code shows them converting them to strings and then returning them that way. This is going to make figuring things out harder, but that's because you're not using the tools given.

fragmede 2y ago
Yes but the language is making it hard to use the tools given. It's easy enough to say it's a skill issue, and say they should have discovered RUST_BACKTRACE=1, but when you're learning the language and trying figure out how to use error objects in the first place the tools given don't work and just give me a string that says I'm doing a dumb shouldn't be so hard.
- nequo 2y ago
  In this case, `RUST_BACKTRACE` is described in Chapter 9 of The Book: https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... I would say that this has good discoverability. If you're learning the language and writing your algorithmic trading platform in it, The Book should probably be the first document that you go to.
- estebank 2y ago
  When encountering panics, the runtime output will tell you how to get the backtrace: thread 'main' panicked at src/main.rs:3:7: called `Option::unwrap()` on a `None` value note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. Maybe they should. It wouldn't be too hard to implement such a lint, but I would expect people to be annoyed by it. I would argue that in 18 months there are plenty of chances to come across any of the documentation and blog posts that explain this, or to ask questions in https://users.rust-lang.org https://users.rust-lang.org. I want our toolchain to be as easy to use as possible, to make it best in class. I have a long list of things I'd like to see improve in Rust. The critiques in the article are not constructive, neither in presentation nor substance.
  - stouset 2y ago
    > It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. I would love to understand where the original author picked up that unfortunate idea from. I’ve never seen someone do this, and it’s very explicitly throwing away all additional error information by converting it to strings. No wonder you can’t figure out where your errors are coming from!
    - steveklabnik 2y ago
      If I would take a guess about a total stranger, it appears that they are a printf debugger. No shade, I am too. But it's not a huge leap to go "the thing I do with errors is print them to the screen, and you print strings to the screen, so strings make sense as error conditions." Furthermore, they seem to enjoy Go, and Go's version of Rust's Error trait provides one method, Error, which returns a string. While I haven't written meaningful Go, and can't speak to its idioms (though as far as I understand, "just turn it into a string" is not idiomatic Go), it's another sign pointing towards "the easiest way to handle errors is to just turn 'em into strings", especially if you're just trying to ship something and don't care about the details.
      - 2y ago
- steveklabnik 2y ago
  I agree that just saying "skill issue" isn't the best, but also, it's totally fine to ask for help rather than write a blog post that says "This is a flawed language design."
  - fragmede 2y ago
    I agree with you, the author should take an L for on that. Trying to handle errors the right way is an exercise in frustration for printf debugging. it's solved by using a debugger but sometimes that's not available, and passing Result<Option <String>,Box<dyn Error>> or whatever around in exactly the right way to error handle is just difficult. I figured it out eventually, but compared to, say, Python there was a steep learning curve. Some people will be able to scale it, others won't. Personally I think that's okay, not everything has to be python easy. Gatekeeping doesn't have to be bad. the real ass awkward reality is that not everyone has that type of reasoning skills to actually get it, and gatekeeping people out because they don't and can't get it doesn't have to be a bad thing. We shouldn't be surprised when someone complains about that though.
    - steveklabnik 2y ago
      I do think that one unfortunate side effect of "the Project doesn't pick winners" is that it would certainly help newcomers to just know that anyhow exists. It could make those initial steps easier.

fragmede 2y ago

Yes but the language is making it hard to use the tools given. It's easy enough to say it's a skill issue, and say they should have discovered RUST_BACKTRACE=1, but when you're learning the language and trying figure out how to use error objects in the first place the tools given don't work and just give me a string that says I'm doing a dumb shouldn't be so hard.

nequo 2y ago
In this case, `RUST_BACKTRACE` is described in Chapter 9 of The Book: https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... I would say that this has good discoverability. If you're learning the language and writing your algorithmic trading platform in it, The Book should probably be the first document that you go to.
estebank 2y ago
When encountering panics, the runtime output will tell you how to get the backtrace: thread 'main' panicked at src/main.rs:3:7: called `Option::unwrap()` on a `None` value note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. Maybe they should. It wouldn't be too hard to implement such a lint, but I would expect people to be annoyed by it. I would argue that in 18 months there are plenty of chances to come across any of the documentation and blog posts that explain this, or to ask questions in https://users.rust-lang.org https://users.rust-lang.org. I want our toolchain to be as easy to use as possible, to make it best in class. I have a long list of things I'd like to see improve in Rust. The critiques in the article are not constructive, neither in presentation nor substance.
- stouset 2y ago
  > It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. I would love to understand where the original author picked up that unfortunate idea from. I’ve never seen someone do this, and it’s very explicitly throwing away all additional error information by converting it to strings. No wonder you can’t figure out where your errors are coming from!
  - steveklabnik 2y ago
    If I would take a guess about a total stranger, it appears that they are a printf debugger. No shade, I am too. But it's not a huge leap to go "the thing I do with errors is print them to the screen, and you print strings to the screen, so strings make sense as error conditions." Furthermore, they seem to enjoy Go, and Go's version of Rust's Error trait provides one method, Error, which returns a string. While I haven't written meaningful Go, and can't speak to its idioms (though as far as I understand, "just turn it into a string" is not idiomatic Go), it's another sign pointing towards "the easiest way to handle errors is to just turn 'em into strings", especially if you're just trying to ship something and don't care about the details.
    - 2y ago
steveklabnik 2y ago
I agree that just saying "skill issue" isn't the best, but also, it's totally fine to ask for help rather than write a blog post that says "This is a flawed language design."
- fragmede 2y ago
  I agree with you, the author should take an L for on that. Trying to handle errors the right way is an exercise in frustration for printf debugging. it's solved by using a debugger but sometimes that's not available, and passing Result<Option <String>,Box<dyn Error>> or whatever around in exactly the right way to error handle is just difficult. I figured it out eventually, but compared to, say, Python there was a steep learning curve. Some people will be able to scale it, others won't. Personally I think that's okay, not everything has to be python easy. Gatekeeping doesn't have to be bad. the real ass awkward reality is that not everyone has that type of reasoning skills to actually get it, and gatekeeping people out because they don't and can't get it doesn't have to be a bad thing. We shouldn't be surprised when someone complains about that though.
  - steveklabnik 2y ago
    I do think that one unfortunate side effect of "the Project doesn't pick winners" is that it would certainly help newcomers to just know that anyhow exists. It could make those initial steps easier.