4 ms·

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 essent

by Mond_ 1y 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.

Thaxll 1y ago
You're assuming that not having a crash would prevent the problem they had.
- jsnell 1y ago
  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.
  - Thaxll 1y ago
    Ok so your Rust program exit gracefuly because of handled deserialization error, how does it helps?
    - jsnell 1y ago
      Why in the world would the program exit due to that? This is a server. I'd you're going to fail entirely due to the error, the natural scope of error propagation is to fail the request. Having the entire program quit would be insane. 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.
      - Thaxll 1y ago
        They said it themself: 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.
- Mond_ 1y ago
  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.
koakuma-chan 1y ago
You just brought up Rust. Welcome to the club.
bjackman 1y ago
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.
- redman25 1y ago
  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?
  - bjackman 1y ago
    "Yes it's an Option but it will never be None, the RPC layer validates the request and will reject the call if this field isn't set. Plumbing error handling into this callback is gonna require significant refactoring here, it's not worth it for a theoretical case so let's just .expect()". 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.

by Mond_ 1y ago

Thaxll 1y ago

You're assuming that not having a crash would prevent the problem they had.

jsnell 1y ago
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.
- Thaxll 1y ago
  Ok so your Rust program exit gracefuly because of handled deserialization error, how does it helps?
  - jsnell 1y ago
    Why in the world would the program exit due to that? This is a server. I'd you're going to fail entirely due to the error, the natural scope of error propagation is to fail the request. Having the entire program quit would be insane. 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.
    - Thaxll 1y ago
      They said it themself: 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.
Mond_ 1y ago
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.

koakuma-chan 1y ago

You just brought up Rust. Welcome to the club.

bjackman 1y ago

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.

redman25 1y ago
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?
- bjackman 1y ago
  "Yes it's an Option but it will never be None, the RPC layer validates the request and will reject the call if this field isn't set. Plumbing error handling into this callback is gonna require significant refactoring here, it's not worth it for a theoretical case so let's just .expect()". 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.