You must log in or register to comment.
Learning C, that smasher would never have stopped.
It would also be emitting significantly less helpful messages.
“What messages?”
Lol yes
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.
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.
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 }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 }
?But then someone will have to deal with it somewhere, better just unwrap it under the carpet.
expr
The amount of people on the internet seriously complaining that both Rust error handling sucks and that
.unwrap();is too verbose is just staggering.I think the problem is that many introductory examples use
unwrap, so many beginner programmers don’t get exposed to alternatives likeunwrap_orand the likes.
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.
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 mean it could be Mutex, or Rwlock or anything atomic. It’s just when I have to out stuff into an Arc<> to pass around I know trouble is coming.
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?
It will become more complex when you start needing circular references in your datastructures.
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
You’ll be fine. You will learn the lifetime stuff and all will work out. It’s not that bad to be honest.
