Gregory's Server@javierg The language matters because segfaulting on invalid input only happens in memory unsafe languages. On a memory safe language you generally have to make a conscious decision about how to handle errors and unexpected situations.
|
8 comments
 @javierg At least with a memory-safe language someone had to make an *active decision* to reliably crash (making this something solvable by policy, e.g. ban such constructs in the linter), as opposed to no decision at all (which is impossible to protect against or have processes that forbid, once you're using a memory unsafe language).  re: > At least with a memory-safe language someone had to make an *active decision* to reliably crash (making this something solvable by policy, e.g. ban such constructs in the linter), I've seen entire teams making concise active decision to break things for the sake of save their ass or the corporate reputation - if any. I agree, it's way better if the programming language has all the controls and tries their best to avoid unconscious bad decisions. |
@marcan and that's exactly how this kind of quality-free coffee is written: assuming nothing wrong ever happens. In "memory safe" languages it's the "reliably crash" that would stay in the code because nobody cares to check if it's replaced with actual error handling.