37
crates.io Postmortem: Broken Crate Downloads
(blog.rust-lang.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Jul 2023
37 points (97.4% liked)
Rust
5960 readers
3 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
I can’t tell if your comment is intentionally sarcastic but it sure sounds like you’re saying “just don’t write buggy code in the first place!”
It's about not ignoring the clear underlying cause of the bug that is screaming at everyone who reads the bug description.
Include something along the lines of "We will use the URL crate and utilize its API to avoid trivial URL construction errors like this one in the future", and I may take your postmortem seriously.
A flawless developer does not exist, and at no point did I fault any developer directly for their development work. But that doesn't mean we should ignore something that is/was clearly and inherently wrong with the code. You would think this is all stating the obvious.
So it's not "just don’t write buggy code in the first place!”. It's "this code could clearly have been written in a way that would have prevented this bug from ever taking place".
And yes, good code matters. A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters. This is Rust afterall. If those things don't matter, then we might as well let the code be written in Python or JS, and fully recommit to the church of TDD.
That basically is the same as saying "next time we will write correct code" in your postmortem, which I don't think is very useful. It's much more useful to say "our code is not structured in a way that makes testing easy" and "our smoke tests should cover the thing that broke." That gives you something actionable to work on that will actually prevent this from happening in the future. Otherwise, you'll end up writing essentially the same postmortem over and over again, each time saying "we will write correct code."
False dichotomy much!
See this postmortem from Cloudflare as an example.
Under "What went wrong", point 1 and 3:
And on what needed to done, point 4
See! Plenty of procedural talk in that postmortem. Plenty of corporate talk too. But you have to mention that a bad backtracking regex was used. And you have to mention that using regexes with no complexity guarantees was glaringly wrong. To not have done so would have been silly. To not even come close to mentioning those things beyond the specific error in that specific regex, and you wouldn't have been taken seriously.