I swear some of these commenters will jerk each other off about how “Rust is bad, actually” even if the root cause of an issue was someone intentionally crashing their app. Where do you even get this kind of attitude from? I’ve been around when Rust was the popular topic in any programming-related discussions and while there was plenty of evangelism and CS-101 experts making wild claims, nothing warrants this kind of irrational hatred. I thought you need to go to the phoronix forums to find people who have such loud opinions with very little actual programming experience, but apparently I was wrong.
RUST AGAIN.
Just throwing this out because I’ve been hammering this Rustholes up and down these threads who claim it’s precious and beyond compare 🤣
I will almost certainly link back to this comment in the future.
RUST AGAIN.
You took this right out of my mouth.
Just because you’re writing in a shiny new language that never misses an opportunity to crow about how memory safe it is, doesn’t mean that you can skip due diligence on input validation, checking every return value and writing exception handlers for even the most unlikely of situations.
Lol
I swear, every time I start to think that I go overboard with this sort of shit in my scripts for work, I either find another ridiculous edge case or a story like this comes out.
But at least it wasn’t a memory leak!!! 😭😭😭
Memory leaks are logic errors, Rust can’t really prevent you from leaking memory.
It’s really hard to do without Rc (or similar) or unsafe.
You can leak memory in perfectly safe Rust, because it is not a bug per se, an example is by using Box::leak
Preventing memory leaks was never in the intentions of Rust. What it tries to safeguard you from are Memory Safety bugs like the infamous and common double free.
Some memory leaks are logic errors, and this is honestly the irony of modern dynamic languages. I have actually gotten into the argument in interviews before - it is arguably safer (and better) to work from maximal static memory allocations with memory safe data objects than it is to implement dynamic memory algorithms just because they are fun coding problems.
It’s crazy that cloudflare of all people even had unwrap enabled. Whenever I use unwrap in some tiny little not important thing I always treat it as a temporary thing that I need to come back and fix before the software is actually ready for anyone to seriously use
There’s nothing more permanent than a “temporary” fix.
Yeah but man, they should have had a CI against this. And reviews! I have refused to merge PRs from friends on hobby projects for less than that
PM: Listen it’s almost December, the whole team decided to cash in PTO next week for thanksgiving, it’s 4pm on a Friday, and the quarter is about to end. We have to move onto next quarter’s OKRs. Is this good enough to ship?
A very tired dev: …lgtm
As always, there’s a clippy rule for that.
I feel like I’ve seen an insane number of error messages in various apps and websites around the
unwrapmethod.But this is on a result type, right? I’d figure the point would be that you would match on it and that the unwrap itself, which if my assumptions are correct, is more like
get value or throw, should either not exist or take a default value. You shouldn’t be able to directly get the value of a monad.There is a function that does what you are asking for.
.unarap_or()
It either unwraps the value or uses a provided default. Personally, i think unwrap() should be renamed unwrap_or_panic() to follow existing conventions and prevent confusion for non-rust programmers.
I don’t think non-rust programmers are programming in Rust, LLMs on the other hand…
If you think only llms can do these kind of beginner mistakes you are mistaken. That’s the whole point of the argument.
“unwrap should not exist” is true as long as you don’t want to ever use the language. If you actually want to use it, you need it. At least while developing.
Some values cannot have a default value. And some cases it’s preferable to panic even if it has a default value.
unwrap is not the problem. Cloudflare’s usage is.
I feel like I’ve seen an insane number of error messages in various apps and websites around the unwrap method.
I suspect this is related to LLM usage somehow. We’ll probably see a lot more of this type of problem (sudden flareups of a particular bad code implementation)
I actually disagree, because I’ve both seen it everywhere and I also work mainly in dotnet, and when I’ve talked to people about option and result types, the first inclination is to have a
.Value, but that defeats the purpose. I’ve done quite a few code reviews where I was essentially saying “you know this will throw, right? Use .Match or .Map instead”.I think the imperative programming backgrounds encourage this line of thinking, since one of the first questions I’ve gotten is “how do I get the value out of an Option? I’m 100% sure it’s there.” And often, surprise, it wasn’t.
Could be, but Rust has been around long enough that we’d see this already, no?
Agreed, that’s what I was trying to say but I’m not great at writing. I’ve seen this in rust and other languages long before llms
There are good reasons to have unwrap or at least expect. There is no reason to use it in the case that Cloudflare used it in.
Rust has exceptions? Is that new?
No, the article is just not very precise with its words. It was causing the program to panic.
They’re probably trying to write it in a way that non-Rust-developers can understand.
Replace uncaught exception for unhanded error.
Well… catch_unwind, but i don’t think you can rely on it.
It not exactly unwrap fault even if it would wrote in other way it still not work cause of wrong SQL request which spamming with results longer than expected to rust here was protecting from memory leak actually
