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.

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

Skill Issue.

For reals though adopting a functional style of programming makes rust extremely pleasant . It’s only when people program in object oriented styles that this gets annoying.

No loops, and no state change make rust devs happy devs.

I’m a OOP programmer.

I wrap everything within Arc<Mutex<>>.

I’m a happy dev.

This is my experience every time I return to learning rust. I’m guessing that if I used it more often than once a quarter with hobby projects I’d stop falling into the same traps.

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.

I mean yah. That’s what it takes. But like when I try to write code around Arc<_> the performance just tanks in highly concurrent work. Maybe it’s an OOP rust skill issue on my end. Lol.

Avoiding this leads, for me at least, to happiness and fearless, performant, concurrent work.

I’m not a huge fan of go-lang but I think they got it right with the don’t communicate by sharing memory thing.

You mean mutex? Arc allows synchronous read only access by multiple threads, so it's not a performance bottleneck. Locking a mutex would be one.

I just started learning rust like two days ago and I haven’t had too many issues with OOP so far… is it going to get considerably worse as the complexity of my projects increases?

You’ll be fine. You will learn the lifetime stuff and all will work out. It’s not that bad to be honest.

I mean it could be Mutex, or Rwlock or anything atomic. It’s just when I have to put stuff into an Arc<> to pass around I know trouble is coming.

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
}

Worse in the sense of more errors, sure, but as you go you’ll pick up more of the rust patterns of thinking and imo it’s very worth it. It’s an odd blend and can be a bit verbose but I definitely prefer it to a pure OO or pure functional style language personally

Learning C, that smasher would never have stopped.

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
}

It will become more complex when you start needing circular references in your datastructures.

It would also be emitting significantly less helpful messages.

"What messages?"

Lol yes

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