Common newbie mistakes or bad practices

[Fredrik]

• Adding heavy dependencies that slow compilation and bloat the compiled program
  – Especially when Serde surprisingly shows up deep in the dependency tree!
• Specifying a custom panic message for panics that are supposed to never happen, for example using expect instead of unwrap
  – Should there be a bug in the program that causes the panic to actually happen, the automatically generated message is good enough to point out the offending code. I don't want someone's poorly written panic message that cannot be optimized away to stay in the data section of my program like a retrovirus.
• Putting a high-level wrapper of a library in the same crate as the underlying library
  – Better make a separate crate for the high-level wrapper. This allows compiling without the wrapper if you don't need it, or forking and customizing the wrapper without forking the underlying library.
• Not reading the license you're using and following the instructions in the license telling how to apply the license
  – Merely putting a copy of a license in your repository doesn't mean the license applies to anything in the repository.
• Only collecting contributions though channels that require accepting Github's terms and conditions and non-free JS code
  – Makes me want to create a platform like crates.io that tracks issues for each crate independently of Github.

[mbrubeck]

@Fredrik

Specifying a custom panic message for panics that are supposed to never happen, for example using expect instead of unwrap
– Should there be a bug in the program that causes the panic to actually happen, the automatically generated message is good enough to point out the offending code.

The default output for unwrap() points to the correct code in Rust 1.42.0 and later. However, in earlier versions of Rust, unwrap would only print the following useless message:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:365

This is why a lot of existing code uses methods like expect to customize the error message, and people who learned Rust before 2020 might still be in the habit of doing this even though it is no longer as useful.

[quinedot]

@mbrubeck

This is why a lot of existing code uses methods like expect to customize the error message, and people who learned Rust before 2020 might still be in the habit of doing this even though it is no longer as useful.

The book and probably many other resources also still recommend it.

[Fredrik]

The book seems to recommend it for a justifiable purpose. Opening a file is an operation that can fail, so it better have a descriptive error message. But I often see custom error messages being used for purely logical operations that can never fail, where the error message is assumed to be unreachable.

[quinedot]

Fair enough. I've used it to document why it should never get hit, but with track caller, those probably should be converted into comments. Definitely expect would get you less side-eye than unwrap when I developed that habit, though.

[KillTheMule]

@Fredrik

But I often see custom error messages being used for purely logical operations that can never fail

Are you sure they're error messages? Because using the expect string for a justification of using it instead of real error handling is just fine.

I also use expect instead of unwrap so that simply grepping for unwrap will tell me there's some code I've written before that I wanted to get back again to check for the error handling. expect signals I went by and checked everything's fine, never mind the message.

[Michael-F-Bryan]

@quinedot

I've used it to document why it should never get hit, but with track caller, those probably should be converted into comments.

I normally use expect(). That way you get the benefit of #[track_caller] and a useful panic message that ends up in logs.