More like yolo deploys without proper scaffolding in place to handle SHTF. Also, if your red-button takes 40 minutes and deploys to mitigate anything, it isn't a red-button.
> Without the appropriate error handling, the null pointer caused the binary to crash. Feature flags are used to gradually enable the feature region by region per project, starting with internal projects, to enable us to catch issues. If this had been flag protected, the issue would have been caught in staging.
Err yeah but the point is languages without null pointers all over the place make it harder to do that in the first place. You normally get some kind of type error at compile time.
Unwrap can definitely bring down a Rust program but it's definitely not nearly as bad as null pointers in C, C++, Java, etc.
1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy.
2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures.
3. You can see `unwrap()`s in code review easily.
4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though.
Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
but a call to unwrap is usually more explicit than a null pointer dereference when you are reviewing code. if you are deserializing something from an external source and calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells. of course maybe everyone agrees the external source should not be sending such data and it goes into prod anyway. but also its possible everyone agrees its worth putting some extra effort into not crashing the process in such a situation because there is too much risk.
More like yolo deploys without proper scaffolding in place to handle SHTF. Also, if your red-button takes 40 minutes and deploys to mitigate anything, it isn't a red-button.
> Without the appropriate error handling, the null pointer caused the binary to crash. Feature flags are used to gradually enable the feature region by region per project, starting with internal projects, to enable us to catch issues. If this had been flag protected, the issue would have been caught in staging.
So some combination of both.
If you write code that crashes on a blank field you'll manage to do that with any language
Err yeah but the point is languages without null pointers all over the place make it harder to do that in the first place. You normally get some kind of type error at compile time.
So like "var quota : string | null"? :-)
2 replies →
Has there been any confirmation it was golang?
Pretty sure it's C++.
inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.
Unwrap can definitely bring down a Rust program but it's definitely not nearly as bad as null pointers in C, C++, Java, etc.
1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy.
2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures.
3. You can see `unwrap()`s in code review easily.
4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though.
Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
but a call to unwrap is usually more explicit than a null pointer dereference when you are reviewing code. if you are deserializing something from an external source and calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells. of course maybe everyone agrees the external source should not be sending such data and it goes into prod anyway. but also its possible everyone agrees its worth putting some extra effort into not crashing the process in such a situation because there is too much risk.
1 reply →
How is panicking the same as dereferencing a null pointer, which is undefined behavior?
2 replies →
you don't even need turing-completeness to write a bug that takes down prod :-)