Comment by Mond_
2 days ago
I mean, I don't want to be a "Keeps bringing up Rust in the comments" sort of guy, but null pointer dereferences are in fact a problem that can be solved essentially completely using strict enough typing and static analysis.
Most existing software stacks (including Google's C++, Go, Java) are by no means in a position to solve this problem, but that doesn't change that it is, in fact, a problem that fundamentally can be solved using types.
Of course, that'd require a full rewrite of the service.
Rust only stops you crashing the process in the "oh, I didn't realise this field can be null" case.
It doesn't help with the "yes, in theory it can be null, but in practice it never will be" case. Once you write .expect() you are crashing the service just as badly as a dereference when your assumptions turn out to be wrong.
The point is the language forces you to explicitly handle the null. You have to make the choice. Using `expect`, the programmer would understand that that is equivalent to a panic. Why would they intentionally panic?
You're assuming that not having a crash would prevent the problem they had.
In this case that seems like a safe assumption? The crash meant there was impact to all customers, not just the ones using the new feature.
Ok so your Rust program exit gracefuly because of handled deserialization error, how does it helps?
2 replies →
I'd say the binary not crashing would certainly be an improvement.
Even better if the type checker specifically highlights the fact that a value can be zero, and prevents compilation of code that doesn't specifically take this possibility into account.
You just brought up Rust. Welcome to the club.