this post was submitted on 05 Jul 2025
261 points (98.9% liked)

Programmer Humor

24790 readers
519 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
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
261
Learning to program in rust (programming.dev)
submitted 1 day ago by KernelPanic@programming.dev to c/programmer_humor@programming.dev
39 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] kubica@fedia.io 67 points 1 day 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.

[–] daniskarma@lemmy.dbzer0.com 1 points 10 hours ago* (last edited 10 hours ago)

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

[–] sbv@sh.itjust.works 40 points 1 day ago (2 children)

?

[–] sukhmel@programming.dev 6 points 1 day ago

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

[–] marcos@lemmy.world 21 points 1 day ago (2 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.

[–] wise_pancake@lemmy.ca 3 points 10 hours ago* (last edited 10 hours 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.

[–] marcos@lemmy.world 2 points 7 hours 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.

[–] magic_lobster_party@fedia.io 17 points 1 day ago

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.

[–] ImplyingImplications@lemmy.ca 7 points 1 day 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
}
[–] shape_warrior_t@programming.dev 13 points 1 day ago (1 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
}
[–] beeb@lemmy.zip 4 points 16 hours ago* (last edited 16 hours 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.