this post was submitted on 05 Jul 2025
317 points (100.0% liked)

Programmer Humor

25026 readers
1518 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 76 points 1 week ago (4 children)

The weird part of rust is replacing straight forward semicolons from other languages with the more verbose .unwrap();.

Just kidding, don't lecture me about it.

[–] [email protected] 49 points 1 week ago (2 children)
[–] [email protected] 6 points 1 week ago

But then someone will have to deal with it somewhere, better just unwrap it under the carpet.

[–] [email protected] 28 points 1 week ago (3 children)

The amount of people on the internet seriously complaining that both Rust error handling sucks and that .unwrap(); is too verbose is just staggering.

[–] [email protected] 2 points 21 hours ago

I will say this: for me, learning rust was 80% un-learning habits from other languages.

People tend to not like it when they have to change habits, especially if those took a long (and painful) time to acquire.

In this particular case, this is the same complaint Go faced with its form of explicit error handling. And Java, for that matter.

Honestly, Rust does a killer job of avoiding checked exceptions and verbose error hooks by way of the ? operator, and requiring all possible match branches to be accounted for. If you embrace errors fully, by using Result<> and custom Error types, your program gets a massive boost in robustness for not a lot of fuss. I recently learned that it gets even better if you embrace enum as a way to define error values, and make sure it implements useful traits like From and Display. With that, error handling code gets a lot more succinct, permitting one to more easily sift through different error values after a call (should you need to). All of that capability far exceeds any perception of clunkyness, IMO.

[–] [email protected] 22 points 1 week ago (1 children)

I think the problem is that many introductory examples use unwrap, so many beginner programmers don’t get exposed to alternatives like unwrap_or and the likes.

[–] [email protected] 5 points 1 week ago

Yeah, we onboarded some folks into a Rust project last year and a few months in, they were genuinely surprised when I told them that unwrapping is pretty bad. Granted, they probably did read about it at some point and just forgot, but that isn't helped by lots of code using .unwrap() either.

[–] [email protected] 3 points 1 week ago* (last edited 1 week ago) (1 children)

I’ll be honest, when I was learning to program in Java I mostly just wrapped errors in an empty try catch to shut them up, with no regard for actually handling them.

I assume most other learners do that too.

[–] [email protected] 4 points 1 week ago

Java requiring you to write every exception that can happen in your code isn't helpful.

Explicit error types are great, but Java managed to make them on a way where you get almost none of the upside and is so full of downsides that indoctrinated a generation into thinking knowing your errors is bad.

[–] [email protected] 9 points 1 week ago (1 children)

Me, every time I try searching a Rust question.

That's easy. Just do:

fn is_second_num_positive() -> bool {
    let input = "123,-45";
    let is_positive =
        input.split(',')
        .collect::<Vec<&str>>()
        .last()
        .unwrap()
        .parse::<i32>()
        .unwrap()
        .is_positive();
    is_positive
}
[–] [email protected] 16 points 1 week ago (2 children)

Can't resist pointing out how you should actually write the function in a "real" scenario (but still not handling errors properly), in case anyone wants to know.

If the list is guaranteed to have exactly two elements:

fn is_second_num_positive_exact(input: &str) -> bool {
    let (_, n) = input.split_once(',').unwrap();
    n.parse::<i32>().unwrap() > 0
}

If you want to test the last element:

fn is_last_num_positive(input: &str) -> bool {
    let n = input.split(',').next_back().unwrap();
    n.parse::<i32>().unwrap() > 0
}

If you want to test the 2nd (1-indexed) element:

fn is_second_num_positive(input: &str) -> bool {
    let n = input.split(',').nth(1).unwrap();
    n.parse::<i32>().unwrap() > 0
}
[–] [email protected] 6 points 1 week ago* (last edited 1 week ago)

Even better to use expect with a short message of what the assumption is: "the string should contain a comma" if it ever panics you'll know exactly why.

[–] [email protected] 4 points 1 week ago

Can still use .is_positive(), though...

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago)

You can also use a shorter version .clone();