Hacker News

Or just by not writing let _ =

Ehh, easy fix

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

Can you get reasonable results without exposing sensitive info? I'm asking because I genuinely have no idea what it's like at their scale

It is a long time and it gets frustrating when there is significant time where there is flailing with no visible progress.

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.

I get that it’s fun to dunk on Rust when a Rust bug surfaces. But is it a bit petty to bring this out when there’s any type of bug of any severity in any Rust software?

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.

Agree. This is warning to people who thought Rust is optional at cloud scale.

Isn't this already Rust?

No. Anyone expecting that hasn't read No Silver Bullet essay.

The Hyper library in question is a Rust library.

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

This does not appear to be a concurrency bug though?

Reminds me of another “slow client”-related bug in gunicorn: https://github.com/benoitc/gunicorn/issues/3334

Hey, you have to justify three engineers full time's worth of salary.

Go does force you too, but it also supports _ as a bypass - because sometimes you do know better. Just not in this case.

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

You could argue the bug happened exactly because hyper's poll_flush treats flushing some but not all data as a successful return, not an error case.

There's a hidden equivocation there. "Handling" errors, as far as the language is concerned, mean you do something with them, but explicitly discarding them is most definitely a "something".

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.

You could say the exact same thing about safety belts and airbags in cars after someone has died in a crash.

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

> I wonder if this bug was found via project glasswing

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