We found a bug in the hyper HTTP library

https://github.com/hyperium/hyper/issues/4022

Saved you 3000 words

https://datatracker.ietf.org/doc/html/rfc9112#section-9.6 (this was already in https://datatracker.ietf.org/doc/html/rfc7230#section-6.6)

The relevant condition here is where one side closed its socket but the other side didn't and keeps sending data to the closed socket. That's obviously an improper way to end a connection. A graceful shutdown does not send RST and ensures all data is received on both sides.

Did you read how they said it took weeks? Would run out of tokens at that rate...

That's a long time, must be frustrating.

I have had long bug hunts (~a month each) and witnessed ones that took much, much longer. But the longest one I witnessed was drawn out because reproduction was initially unreliable and could take weeks to months. Thankfully, reproduction was by letting a box sit in a corner while tje people involved moved on to other tasks. This kept everybody sane.

Did you read the article, or are you a "use rust" parrot / bot based on titles?

Brooks was expecting such "Silver Bullet" improvements as often as every few decades, we're arguably overdue significantly. He cites Ada as an example of where such an improvement might come from, well, Rust isn't Ada but a lot of the same ideas about correctness are present.

Google reports order of magnitude changes from their Rust work for example.

Not really. If anything I'm pretty sure Fred would compare it to Ada:

    > Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster, It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions.

Google reports 4x fewer (and still falling) rollbacks for Rust versus C++ in their Android development for example. That's not 10x but it's pretty sizeable.

Naturally there are several ideological questions between that approach from the anti GC crowd, and adopting Rust instead.

Not that breaks the C++ vs Rust from your comment, though.

Folks that wonder pre-history tech with amazement and lack of understanding of how it used to work in first place.

https://news.ycombinator.com/item?id=48727323

The Red Black tree, C++ std::map is a classic example. It has these very attractive theoretical properties, but then you try one for real in C++ and oh, why is this so slow and so RAM hungry? Well yeah, those are only real world problems, the big-O numbers don't care about that.

Ironically there are C# implementations that perform better, exactly because they were developed without WG21 working environment, in a compiled managed language.

For all the performance minded talk, the walk doesn't always follow.

Also std::map cannot be improved by existing processes.

In this case a small minority of requests were getting truncated responses.

No one said Rust software is bug free. If someone thinks that they’ve been seriously misled.

Why even bother with measures that prevent many problems if they won't prevent all of them, right?

It's the same argument anti-vaxers love to make. "Well you can still get covid after getting the shot", which is something I read and heard quite a lot. That doesn't make the thing useless.

Humans are really dumb.

This I'd an example of people not grasping simple probabilities. Forced to play Russian Roulette they prefer the revolver with 5 bullets in its chambers or the one with just a single bullet, because in both cases people die.

Other concepts many people do not grasp are feedback-loops and exponentials. And by not grasp I mean: You explain it to them, the nod along and when faced with the thing in slightly different clothes they will actively deny it'd existence.

Rust never promised it'll let programmers turn off their brain, that's what LLMs are for.

From a human perspective we can consider that not handling the error.

But the language has no mechanism for "knowing" that discarding the error is wrong. Discarding errors is a fully valid mechanism that we must be able to do in a program because it is sometimes correct. There really isn't even a sensible way to define a way to "force" a user to "handle" errors. The language can only be designed to make it hard to forget to "handle" them somehow in the way the language sees, but it is always possible for the user to incorrectly handle them, of which discarding them when they shouldn't have is only one particularly cognitively-available option but is hardly the full scope of possibilities. Probably isn't even the most common mistake to make, I would imagine there are far more errors that are not handled "correctly" than ones that are spuriously discarded.

Note I keep saying "language" rather than Rust. All a language can do is surface the issue, and Rust does that. It can't force good code. No language can.

    #[allow(clippy::let_underscore_untyped,clippy::let_underscore_must_use)]
    let _ = self.poll_flush(cx)?;

You can always write the wrong code if you want it enough. But hopefully a warning would have prompted someone to think harder about this flow.

IMHO the goal is usually for the compiler not to make these decisions but to provide the tools for the APIs people build to make them. That's kind of passing the buck, though.

I guess in this case the core problem is that the API for these I/O calls has no representation in the type system for what's happening to the buffer. Proxying it as ‘the programmer must think about this code path’ is a reasonable best-effort but, evidently, sometimes inadequate.

    #[allow(clippy::allow_attributes_without_reason,clippy::let_underscore_untyped,clippy::let_underscore_must_use)]
    let _ = self.poll_flush(cx)?;

You know what might've solved this though? Using threads instead of async

Rust has never promised to solve race conditions as a whole.

*should clarify, Node.js, PHP, and Haskell did ship patches. Python, Ruby, Erlang, and Go opted for documentation updates; Java went "won't fix."

This reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.

`curl --http1.1` sends `Connection: Close` so sender (hyper) must attempt to shutdown connection after sending whole body. Surely any network is slower than memory copy into socket kernel buffers, so it must reliably trigger condition "buffer flush can't be done in one go" and thus trigger early TCP shutdown.