this post was submitted on 05 May 2025
474 points (98.8% liked)

Programmer Humor

23030 readers
1781 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] 3 points 8 hours ago* (last edited 8 hours ago)

When handling things that are serialized over the wire, you have to do it this way. Yes, you can use typed serialization formats, but in a string-based serializer, there's nothing stopping the other system from sending "0.0000005" on a field that should be an int. If you don't validate that it's an int, you would just pass that value to your equivalent of parseInt().

If you do validate that it's an int, then it still didn't matter if the language has static typing or not. You're doing that at runtime or you're not.

In Rust, doing "0.00005".to_string().parse::<i32>().unwrap() causes a panic on the unwrap() from an invalid digit. However, that's runtime. It's not something the type system can handle statically. The real benefit here, I think, is that it at least forced you to consider that the invalid input could have unexpected results. This is a pretty good reason to be careful about putting unwrap() on everything. The compiler isn't going to save you here.