1
crates.io Postmortem: Broken Crate Downloads (blog.rust-lang.org)
submitted 3 years ago by to c/rust@programming.dev
22 comments fedilink hide all child comments

all 22 comments

sorted by: hot top controversial new old
[–] 1 point 3 years ago

We need clearer rules on which pull requests require code reviews.

Weird to me that any pull request would not require a code review.

  • permalink
  • fedilink
  • source
    •
    [–] 0 points 3 years ago (2 children)

    The code had not been unit tested before

    Because the smoke test procedure on our staging environment is currently a completely manual process without any automation.

    Why do we have to keep learning to test and automate our tests as hard lessons?

    Why do software engineering lectures not teach us about testing? If I were asked to teach software engineering (which TBH I shouldn't be qualified to do just yet) I'd start with testing.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    Funny how you got successfully distracted by the procedural failure dance, where the obvious, as expected, got zero mentions. Giving software engineering lectures seems to be right up your alley.

    If I was the author of that commit, or any crates.io developer, I would have wanted to be called out for not constructing URLs correctly. That's the obvious first fault here. Not even hinting at that would have felt so cringe.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    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.

    Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn't better or worse than other languages. If those problems are prominent in your domain(such as you have to write a ton of concurrent code), Rust makes sense. Otherwise being well rested will have a bigger impact on the quality of your code than the best type system in the world.

    In terms of dev practices, the only practice demonstrated to have a consistent positive impact on code quality is code reviews. Testing as well, but whether it's TDD or other kinds of testing doesn't really matter.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    research shows otherwise

    Can you share that research?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    https://youtu.be/WELBnE33dpY

    It's not that there is evidence that it doesn't matter, but there is no evidence showing that it does.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages.

    Can you concede, at least to yourself, that you made ^ this ^ up?

    By the way, what you claimed "research shows" is so ridiculous that it's hilarious that you wrote it while being serious.

    Hell, I cheekily mentioned Python and JS in particular because the former introduced type hints and the latter triggered creating TS as a saner shield.

    Btw, that wrongly-constructed URL wasn't even an external one. We literally have web frameworks that make sure non-external URLs with invalid paths are impossible to construct. In other words, attempting to construct a wrong one would be a compile error.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    By the way, what you claimed “research shows” is so ridiculous that it’s hilarious that you wrote it while being serious.

    There is still no research that definitively shows that static types reduce defects more than dynamic types, this is a fact. Turns out we are incredibly bad at studying this, so I don't know how you can say definitively that it is the case when even the people who study this for a living are not able to make that case.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago* (1 child)

    Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages.

    Come on. What was requested by the other user is clear, I think.

    You made this specific claim. Can you link to the research showing that? Actual research showing that "Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages", not a YT video from a wannabe intellectual talking abstracts and siting some generic studies.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    It was my mistake, I said that we definitely know they don't vs. there is no evidence showing that there is. There aren't much studies to back this up. The whole point of the talk is that software engineering as a discipline is really poorly studied and we tend to make assertions like this without actually validating them.

    If I was betting money on this(I.e. deciding where to focus my investment), the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC'd language because the kinds of bugs that you face in Web apps aren't really the kinds of issues that a borrow checker will help you with. The whole point of Rust being difficult is that it saves you time down the line, if it's difficult and it doesn't then that tradeoff doesn't make sense.

    Hilel teaches formal verification for a living, he very much sees the value of automatically proving properties about your program, as do I, but the reality is that the typesystem doesn't necessarily help as much as we think it does.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago

    the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC’d language because the kinds of bugs that you face in Web apps aren’t really the kinds of issues that a borrow checker will help you with.

    It's quite reductionist (and weird) to describe Rust's type system in terms of it's borrow-checker only, ditto for describing the other simply as "GC'd languages".

    The borrow-checker together with move semantics and RAII are a small, if dominating -especially for beginners-, part of Rust's type system. There are many other very relevant aspects, type classes (traits), sum types (enums), hell, not being OOP alone is a big win for many.

    Talking about Rust only in terms of its type system would also be reductionist. The macro system alone is a big differentiator (I would know, because I've been working on a proc-macro crate for sometime which will support (de-)serializing a format with both more flexibility and reliability than what serde can offer).

    Even talking about Rust only in terms of the language is reductionist! The ecosystem and tooling... okay, I will stop reaching further here.

    Talking about the other as "GC'd languages" is also reductionist and weird, since it puts, for example, Go (lol) and Haskell on the same bracket. And that's two strongly and statically typed languages. I could have picked two languages that are even more different than each other. "GC" as a differentiator for languages is actually even more reductionist than "borrow checker" for Rust.

    The whole point of Rust being difficult is that it saves you time down the line

    Neither Rust is actively trying to be difficult, nor is it really difficult beyond some early friction while learning the language, and even that friction is overblown often by many.

    We do actually have some data on this (I wouldn't dare calling it "research"). There is this part which actually relates to one of the arguments made in your YouTube link:

    And, it’s not just correct—it’s also easy to review. More than half of respondents say that Rust code is incredibly easy to review. As an engineering manager, that result is in many ways at least as interesting to me as the code authoring results, since code reviewing is at least as large a part of the role of a professional software engineer as authoring.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 3 years ago (1 child)

    I've always thought it weird that the intro CS course I took at my university didn't even mention unit testing. After being in the industry for several years, it's become obvious that the majority of what I do is just writing tests.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago* (1 child)

    And then there's me, who almost never writes unit tests 😬

    (With strong typing I can minimize explicit tests, and I like to iterate fast, but I guess it really depends on what you're developing, backend in production that is not allowed to fail, is probably something different than a game)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    Unit tests shouldn't be testing types, even if your language isn't typed. It should be testing logic and behavior. If there's an if condition, it should be tested.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    Yeah you're right, tests should test logic. But static typing certainly helps reducing a lot of tests, which would be necessary in different untyped languages. Also you can sometimes encode your logic in types. Typing also helps reducing logic issues. But as previously said, it depends on what you're doing. I'm prototyping/researching a lot, and tests often hinder progress for me. Maintaining a backend in production is a different story.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 3 years ago (1 child)

    That is absolutely true as well. We're porting a codebase to TypeScript and we were able to eliminate a bunch of test cases that were essentially testing type-correctness (e.g. can't pass a boolean to a date processing library). But those were bad tests to begin with, because there was no good reason for those tests to exist to begin with (we were pretty exhaustive with the invalid type checking even when the intended types were obvious).

    Strict typing helps eliminate useless tests. And Rust types go further than most languages, such as exhaustive match, types that can exclude zero, and the near-complete lack of a null value.

    If you're never going to publish the code, I agree, tests aren't necessarily helpful. Then again, I find writing tests helps me understand my own code better, so I still do it when doing research tasks (e.g. we were testing the potential performance benefits of porting an expensive algorithm to Rust, so my tests helped me benchmark it), though my tests are a lot less exhaustive and tend to be more happy path integration tests instead of proper unit tests.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    I find writing tests helps me understand my own code better, so I still do it when doing research tasks

    Hmm interesting, I try to optimize readability of the actual code itself, so that when I read it again after some time, that I quickly get what this is about, if there's a edge-case or something I thought about while coding, I'll just add a TODO comment or something like that. I feel like reading tests is a "waste of time" for me most of the time (hard take I know ^^).

    But all this obviously only applies for researching and fluid code (code that likely will be refactored/rewritten soon), when it's solid code targeting production etc. I'll add unit tests if friction/hassle is low, and integration/E2E tests for the overall thing. But as I said, I'm mostly in fluid/fast moving codebases that are more difficult to test (e.g. because it does gpu rendering or something like that).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    When I jump into a new codebase, my first instinct is to look over the examples and the unit tests to get a feel for how things are intended to work.

    When prototyping, I generally write a few "unit" tests as a form of example code to show basic usage. For example, if I'm writing a compiler for a new toy language, I'll write some unit tests for each basic feature of the language. If I'm writing networking code (e.g. a game server), I'll write some client and server tests that demonstrate valid and invalid packets. These generally fall somewhere between unit and integration tests, but I do them in a unit test style. When the project stabilizes, I'll go through and rewrite those tests to be narrower in scope, broader in line coverage, and simpler, and keep a few as examples (maybe extract to the readme or something).

    That's my workflow, and I like knowing that at least part of it is tested. When I mess with stuff, I have a formal step to change the tests as a form of documenting the change I made, and I'll usually leave extensive comments on the test to describe the relevance.

    Code readability counts, but I don't think it's enough. The codebase I work on day to day is quite readable, but it's very complex since there are hundreds of thousands of lines of code across over a dozen microservices, and there's a lot of complexity at the boundaries. When I joined the project, I read through a lot of the tests, which was way more helpful to me than reading the code directly. The code describes "how," but it doesn't explain "what" or "why." Tests get into "what" extensively, and "why" can be understood by the types of tests developers choose to write.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 years ago (1 child)

    For example, if I’m writing a compiler for a new toy language

    Ok, thinking about it (since I wrote a toy language not so long ago), this is probably a perfect example where unit tests make sense almost everywhere (even for prototyping, say parser).

    I think it definitely depends what you're doing, writing unit tests for prototype graphics (engine) code is no fun (and I see no real benefit).

    Code readability counts, but I don’t think it’s enough.

    I think it depends, For general architecture, E2E or integration tests definitely make sense, for finer-grained code, I think documentation (Rust doc) of the functions in question should be enough to understand what they do (including some examples how to use them, could be tests, often examples (similar as in std rust) in the rust doc are enough IMHO, and otherwise the code itself is the documentation (being able to read code fast is a valuable skill I guess). That obviously doesn't apply for everything (think about highly theoretical computer science or math code), but yeah it depends...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •