1. 21
  1.  

  2. 3

    I find it interesting that this got no comments the last time it was submitted. I have half a thought that it might be because there’s nothing incorrect in here, but that can’t be it: usually if you post something opinionated and correct, at least one loudly opinionated incorrect person will show up. So it’s a mystery to me. ;)

    I think there’s a 1:1 relationship between section 1 of this article and (what I got out of reading) the Crash-Only Software paper. https://www.usenix.org/conference/hotos-ix/crash-only-software

    One thing I think this talk omits is an explicit admonition to refrain from doing silly “clever” things. e.g. int xs[2], y; memset(xs, 0, 3 * sizeof int); /* clear xs and y */ should not be written (except for silly circumstances like working around a bug in a weird shitty compiler or whatever; example taken from a post about static analysis a while ago).

    1. 2

      Using UUIDs (or random keys) in a database is not always the best idea. At least not for the clustered index. It’s an easy and quick way to have a highly fragmented and sparsely populated database. This was a massive issue for both performance and disk usage when using MSSQL (although the express version had a 10GiB per database limit) on a piece of commercial software I once worked on.

      Moreover, crashing early is great if you’re writing a daemon, but it’s equally important to stress ensuring that any persistent state changes your application undergoes are handled in a transactional manner. Otherwise you’re not much better off than if you were to just pretend like the thing you didn’t plan for didn’t happen. Also, it should never be done for libraries (would-be crashes should be turned into explicit errors, although it’s unclear what those errors should say).

      Stories with similar links:

      1. Write code that's easy to delete, and easy to debug too via cleanshirt 3 years ago | 30 points | no comments