Null pointer dereference has nothing to do with that problem, they have billions of loc you think that kind of issue will never happen?
This is 100% a process problem.
This is 100% a process problem.
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.
And when the failures are request-scoped, you're back to the outage not being global but affecting only the customers using this feature with a bad config.
We will modularize Service Control’s architecture, so the functionality is isolated and fails open. Thus, if a corresponding check fails, Service Control can still serve API requests.
It's clear that they have issues in the service itself not related to language.
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.
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.
People say this kinda thing every day. It's just as easy to say in Rust terminology as any other ecosystem.
Rust has a lot of crucial benefits but "you can't crash the process by making lazy assumptions" isn't one of them.