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.
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 theunwrap()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 puttingunwrap()on everything. The compiler isn’t going to save you here.