“how to write sloppy rust code and squander most of the advantages of the language”
Only half serious. But I think really the only point that I agree with is taking the easy way out with the borrow checker. I mean, at least try to borrow when it’s idiomatic, but if you get frustrated, clone (or move) instead.
Error handling when done well is not much harder than unwrapping everything, and you get many advantages. Learn to use thiserror for your library crates and anyhow for executables.
I also agree that you should avoid unsafe 99% of the time. If you think you need it, you probably don’t.
I see this post as an advice to learn gradually, and to write sloppy but painless code initially. Then when you have the basics, you can add the more idiomatic and tricky parts.
I have a strict no-unsafe policy. My projects don’t need anything unsafe provides, so needing it means my structure is bad. Any unsafe blocks should only be in external crates and fully tested.
I’m also a big fan of getting function signatures right, even if they don’t behave properly. For example, if I know a function could error, I’ll go ahead and have it return a result even if every error path uses .expect(). That way my refactors are limited to just those functions, and probably not the functions that call it.
I’m a fan of writing relatively dirty code, as long as the dirty parts are obvious (e.g. have a comment explaining why certain shortcuts were made). But as much as possible, make the function signatures correct so refactors are easier.
“how to write sloppy rust code and squander most of the advantages of the language”
Only half serious. But I think really the only point that I agree with is taking the easy way out with the borrow checker. I mean, at least try to borrow when it’s idiomatic, but if you get frustrated, clone (or move) instead.
Error handling when done well is not much harder than unwrapping everything, and you get many advantages. Learn to use
thiserrorfor your library crates andanyhowfor executables.I also agree that you should avoid
unsafe99% of the time. If you think you need it, you probably don’t.I see this post as an advice to learn gradually, and to write sloppy but painless code initially. Then when you have the basics, you can add the more idiomatic and tricky parts.
Exactly.
I have a strict no-
unsafepolicy. My projects don’t need anythingunsafeprovides, so needing it means my structure is bad. Anyunsafeblocks should only be in external crates and fully tested.I’m also a big fan of getting function signatures right, even if they don’t behave properly. For example, if I know a function could error, I’ll go ahead and have it return a result even if every error path uses
.expect(). That way my refactors are limited to just those functions, and probably not the functions that call it.I’m a fan of writing relatively dirty code, as long as the dirty parts are obvious (e.g. have a comment explaining why certain shortcuts were made). But as much as possible, make the function signatures correct so refactors are easier.