alt Hacker News> In the recent Cloudlfare outage Cloudlflare's proxy service went down directly due to an unwrap when reading a config file. Me and many other developers jumped the shark, calling out Cloudflare on their best practices. In Cloudflare's defense they treated this file as trusted input and never expected it to be malformed. Due to circumstances the file became invalid causing the programs assumption's to break.
"Trusted" is a different category from "valid" for a reason. Especially if you're working in a compiled language on something as important as that, anything that isn't either part of the code itself or in a format where literally every byte sequence is acceptable, should be treated as potentially malformed. There is nothing compiling the config file.
> Why is this better than NodeJS
... That feels like it really came out of nowhere, and after seeing so much code to implement what other languages have as a first-class feature (albeit with trade-offs that Rust clearly wanted to avoid), it comes across almost as a coping mechanism.
Replies
And it was treated as potentially malformed and hence the panic. That's what panic is for! When invariants are not upheld at runtime, in Cloudflare's case an abnormal amount of entries IIRC.
I mean, if the error was handled what would you have done if not crashing the service with an error message?
I think the post's point is that you don't panic if someone submits a malformed PDF (you just reject their request) but I don't think there's any way to gracefully handle a malformed config file that is core to the service.
>That feels like it really came out of nowhere, and after seeing so much code to implement what other languages have as a first-class feature (albeit with trade-offs that Rust clearly wanted to avoid), it comes across almost as a coping mechanism.
It's really not fair to compare these when most of the errors of one language are caught at compile time by the other.
It reminds me of that scene from silicon valley "Anything related to errors sounds like your area
https://youtu.be/oyVksFviJVE?si=NVq9xjd1uCnhZkPz&t=55
Can we not just agree that interpreted languages (save the Ackshually) like python and node need a more elaborate error handling system because they have more errors than compiled languages? It's not a holy war thing, I'm not on either side, in fact I use interpreted languages more than compiled languages, but it's just one of the very well-known trade-offs.
In the alternative, you would at least admit that error handling in an interpreted language is completely different than error handling in a compiled language.
Nodejs and rust are the languages that I’m most familiar. I mostly mean that part to serve as a contrasting paragraph between the two paradigms. The amount of code is high in rust, even higher due to me writing the most pedantic error possible. If you really want a more try catch approach you can do that with something like dyn error or anyhow. The point is it gives you choice