4 ms·

> They keep assertions enabled in production. Never understood why we turn those off. An assert failing in prod is an assert that I desperately want to know ab

• mcherm 1y ago
  I like to write assertions that aren't always easy to check. Like asserting that a list is sorted.
  • flir 1y ago
    That sounds easy to check. Can you expand on this, because I don't understand.
    • maverwa 1y ago
      its easy as in "simple to implement and execute" but not cheap, because it may require scanning large amounts of memory. You have to visit every list entry. Whats trivial for a very small list, may be a no-go for gigabyte-sized lists.
      • flir 1y ago
        Ah I see. That's the bit of the conversation I was trying to head off with "rhetorical" :)
    • hxtk 1y ago
      Meaning computationally. It would cost a lot of cycles to keep that enabled in production. It’s only O(n), but if I check that assertion in my binary search function then it might as well have been linear search.
    • pjmlp 1y ago
      Basically this could be something like this, D based example: void process_list(List aList) in(aList.isSorted, "List must be sorted!") do { // do something } However the O() cost of calling isSorted() has an impact on overall cost for process_list() on every call, hence why the way contracts are executed is usually configurable in languages that have them available.
  • pjmlp 1y ago
    Then you want Design By Contract, dependent types, or formal verification. However, several factors have to be taken into account regarding performance impact when they get cleverly written, thus in manys cases they can only be fully turned on during debug builds.
    • justinclift 1y ago
      Out of curiosity, have you looked at Cue before? It seems to be used for stuff like this, though I'm yet to really look into it properly. https://cuelang.org https://cuelang.org
      • pjmlp 1y ago
        No, yet another language to discover, thanks.
  • matklad 1y ago
    Yeah, there's actually trickiness here. Another curveball is that, with simulation testing, you generally want more assertions to catch more bugs, but slow assertions can _reduce_ testing efficiency by requiring more CPU time per iteration! But then, if you know, at comptime, that the list is going to be short, you might as well do O(N^2) verification! We captured these consideration in the internal docs here: https://github.com/tigerbeetle/tigerbeetle/blob/0.16.60/src/constants.zig#L776-L795 https://github.com/tigerbeetle/tigerbeetle/blob/0.16.60/src/...
• Cthulhu_ 1y ago
  On paper it's because assertions are only checks for developers to make sure they don't misuse an API. They still have values if it's user input, but at that stage, it would be better to change it to business logic like a proper error message returned to the end-user.
• TZubiri 1y ago
  Because the very raison d'etre of asserts is to be a compile time/test time check. If you wanted them to run in production, you wouldn't use an assert, you would just run an if. Otherwise what's an assert to you? A mildly convenient sugar syntax alternative to if statements?
  • flir 1y ago
    > A mildly convenient sugar syntax alternative to if statements? Yup.
  • kevinqi 1y ago
    right, it is just syntactic sugar, but if that wasn't helpful then why have it in dev either? I find it more confusing to have asserts be stripped, which creates an implicit dev/prod discrepancy
  • swiftcoder 1y ago
    That a semantic we've all just sort of inherited from C - I don't know we're required to be bound by it forever. The word itself doesn't imply that assertions would be contextually disabled.
    • TZubiri 1y ago
      semantics are as if not more important than the technical execution. Bits are all abstractions anyways, what's important is the meaning we assign to them.
• kstenerud 1y ago
  It's historical: turning off assertions made the code run faster. But nowadays an extra comparison is no biggie, especially if the compiler can hint at which way it's likely to go.