Hacker News Reader

In this case, `RUST_BACKTRACE` is described in Chapter 9 of The Book:

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.

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.

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.

> 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!

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.

> (though as far as I understand, "just turn it into a string" is not idiomatic Go)

Sadly while I’ve seen many argue that it’s not idiomatic go, I’ve yet to see more than a handful of projects in the wild that don’t simply `return nil, err` because anything more than that is excruciating given the number of those lines in any given project.

I can't cite my sources, but I recently started learning Rust and I've been doing this. I would guess that I picked it up from the Rust book, since that's been my primary learning source.

I know I _could_ define my own error type, but that's tedious, especially if there are many types of errors to handle. For my (non-production) purposes it's been fine.

What's the idiomatic way to handle errors? Is there a way to collect more detailed error information without excessive boilerplate?

A common but of advice is “use anyhow for applications and thiserror for libraries” but what it really boils down to is, anyhow is good for handling errors, and thiserror is good for defining your own error types.

The docs have good examples of basic usage: https://docs.rs/anyhow/latest/anyhow/

I'll be blunt, the Rust community is not known for being a warm fuzzy place to go ask stupid questions and walk away not feeling like a dumb fuck. Hoping people will wander into the right place to ask rust questions is a non-starter.

You don't control Stack Overflow or Reddit, or any number of slack/discords, so I don't know how I'd address that problem, but it's true.

> Hoping people will wander into the right place to ask rust questions is a non-starter.

https://users.rust-lang.org is moderated by the project. It is linked from the https://www.rust-lang.org/ footer and more prominently from https://www.rust-lang.org/community. Searching for "rust forum" it is the first thing that comes up.

Reddit is also moderated, but the cultural issues of that whole site, as well as those of StackOverflow, are well known by now.

I do my best to set a tone and lead by example whenever possible. Most of the times I've seen threads turn sour, it is usually catalyzed by people being unwilling to listen and acting hot heatedly to begin with. I've seen r/rust discussions where the article being discussed was far more critical of the language/toolchain than this one, but with far more constructive communication style and substantive analysis. The quality of the conversation in those cases have been much better.

Feel free to point me towards toxic community behavior and I'll do my best to address it through every mean available to me. I can't promise that there will be dramatic changes, but I certainly do my best to call out bad behavior and try to foster a space I can be proud to belong to. Then again, I do not spend much time in any of the sites you mention, so I can easily be missing bad behavior.

I would also say that even if you don't want to interact with people (for any reason), that's not an excuse to not seek out official or unofficial documentation. There is a non-comprehensive list at https://www.rust-lang.org/learn.

The OP had resources available to learn how to deal with errors in a more idiomatic way than he did:

- https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

- https://doc.rust-lang.org/rust-by-example/error/multiple_err...

Really? I've gotten the sense that the Rust community is more kind to noobs than average. Not that the average is great, but still.

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."

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.

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.