this post was submitted on 21 Nov 2025
248 points (97.0% liked)
Technology
76992 readers
3094 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 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.