4 ms·

These are the guidelines that the Rust language standard library holds itself too, and tend to be good advice for authors of libraries. By no means should anyo

These are the guidelines that the Rust language standard library holds itself too, and tend to be good advice for authors of libraries. By no means should anyone be intimidated by this. This list is, well, something like a code review guide similar to what you'd find to make changes to Postgres or Python. New APIs that are part of the standard library need to be be consistent, performant, debuggable, documented, and so on. Following this list for a hobby, side project, or for the 0.1.0 release of a new library is entirely unnecessary.

rdpintqogeogsaa 5y ago
> Following this list for a hobby, side project, or for the 0.1.0 release of a new library is entirely unnecessary. This may be a hot take, but I'll go and take my chances. Following this list for a hobby or side project or even an initial release of a library is a very good idea. It's hard to tell what kinds of libraries will or won't catch on. As soon as you have downstream users, they will get annoyed by churn. If given a checklist, it seems reasonable to me to expect people to actually follow it out of obligation to your future downstream consumers of the library. Not only that, but I believe that most of the things on that list boils down to good engineering. Following good practice early on even just in a hobby/side project will be rewarded as the project grows. By releasing a library (even as a 0.1.0), you imply that you expect it to be at least usable for some kind of usage. Releasing known-bad code is something nobody would do, especially since every major Git repostory hoster lets you have private repositories.
- seoaeu 5y ago
  Sure you shouldn't go out of your way to violate the suggestions on the list, but you also shouldn't be afraid to publish a project just because you haven't meticulously gone through it and checked off every item
- tialaramex 5y ago
  > Releasing known-bad code is something nobody would do Mmm. I guess it depends how mischievous people are. Is https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate known-bad code? Take misfortunate::Comte which claims to be an ExactSizeIterator but lies and with a simple "tap" from your wand produces an infinite number of cloned Rabbits ? OK, how about Mara's https://crates.io/crates/whichever-compiles https://crates.io/crates/whichever-compiles or https://crates.io/crates/nightly-crimes https://crates.io/crates/nightly-crimes ? I mean, maybe I'm a bad person for writing misfortunate, but is Mara, Rust's library team lead, a bad person?
  - AaronFriel 5y ago
    I think the person you're replying to wasn't suggesting those are bad people, but it's hard to dispute that "misfortunate" which violates trait contracts is "bad code". It's well written, good for some definition of good, but also it will definitely break callers that rely on the invariants traits represent and by that meaning, it is "bad code". Fortunately, these people are very clever, very good Rust developers and they are not maliciously dropping nightly crimes into widely used crates :)
- stouset 5y ago
  100%. I haven’t read the whole list yet, but all of them I’ve seen so far are extremely trivial conventions. None of these should be difficult or time-consuming for even a novice Rustscean to follow.

rdpintqogeogsaa 5y ago

> Following this list for a hobby, side project, or for the 0.1.0 release of a new library is entirely unnecessary. This may be a hot take, but I'll go and take my chances. Following this list for a hobby or side project or even an initial release of a library is a very good idea. It's hard to tell what kinds of libraries will or won't catch on. As soon as you have downstream users, they will get annoyed by churn. If given a checklist, it seems reasonable to me to expect people to actually follow it out of obligation to your future downstream consumers of the library. Not only that, but I believe that most of the things on that list boils down to good engineering. Following good practice early on even just in a hobby/side project will be rewarded as the project grows. By releasing a library (even as a 0.1.0), you imply that you expect it to be at least usable for some kind of usage. Releasing known-bad code is something nobody would do, especially since every major Git repostory hoster lets you have private repositories.

seoaeu 5y ago
Sure you shouldn't go out of your way to violate the suggestions on the list, but you also shouldn't be afraid to publish a project just because you haven't meticulously gone through it and checked off every item
tialaramex 5y ago
> Releasing known-bad code is something nobody would do Mmm. I guess it depends how mischievous people are. Is https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate known-bad code? Take misfortunate::Comte which claims to be an ExactSizeIterator but lies and with a simple "tap" from your wand produces an infinite number of cloned Rabbits ? OK, how about Mara's https://crates.io/crates/whichever-compiles https://crates.io/crates/whichever-compiles or https://crates.io/crates/nightly-crimes https://crates.io/crates/nightly-crimes ? I mean, maybe I'm a bad person for writing misfortunate, but is Mara, Rust's library team lead, a bad person?
- AaronFriel 5y ago
  I think the person you're replying to wasn't suggesting those are bad people, but it's hard to dispute that "misfortunate" which violates trait contracts is "bad code". It's well written, good for some definition of good, but also it will definitely break callers that rely on the invariants traits represent and by that meaning, it is "bad code". Fortunately, these people are very clever, very good Rust developers and they are not maliciously dropping nightly crimes into widely used crates :)
stouset 5y ago
100%. I haven’t read the whole list yet, but all of them I’ve seen so far are extremely trivial conventions. None of these should be difficult or time-consuming for even a novice Rustscean to follow.