A friend told me about rust around 8 years ago and this was very much my first experience (at least with &str and lifetimes and borrow errors).
this post was submitted on 05 Jul 2025
183 points (98.9% liked)
Programmer Humor
24772 readers
852 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
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Learning C, that smasher would never have stopped.
It would also be emitting significantly less helpful messages.
"What messages?"
Lol yes
Segmentation fault?
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
}
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.
?
But then someone will have to deal with it somewhere, better just unwrap it under the carpet.
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 like unwrap_or and the likes.
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 find that the error messages themselves are a great tool for learning when it comes to Rust.
Eh, I’m not entirely sold on that idea.
I think they do a good job of pointing out “this is a behavior/feature of Rust you need to understand.” However they can send you down the wrong path of correction.
The compiler error mentioning static lifetime specifiers of &str demonstrates both. It indicates to the developer that ownership and scopes will play a significant role when defining and accessing data. The error though will guide them towards researching how to define static lifetimes and possibly believe that they will need to set this in their functions and structs. Each time you look at questions about this error in places like Stack Overflow with example code you’ll find suggested solutions explaining that a manually-defined static lifetime isn’t necessary to resolve the problem.
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 put 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.
You’ll be fine. You will learn the lifetime stuff and all will work out. It’s not that bad to be honest.
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