3 ms·

Also known as contract programming vs. defensive programming. This argument is very old, is not specific to golang, and I have found myself on both sides at dif

• Sharlin 4mo ago
  Fortunately we have type systems to encode many contracts at compile time, including stuff like optionality. Certainly no modern language would still repeat Hoare’s "billion dollar mistake"? Right? …Oh.
  • tialaramex 4mo ago
    It's so bad that here we are in the 21st century and there are even still people who insist it wasn't a mistake e.g.: https://www.gingerbill.org/article/2026/01/02/was-it-really-a-billion-dollar-mistake/ https://www.gingerbill.org/article/2026/01/02/was-it-really-...
    • bvrmn 4mo ago
      It's quite a delusional take from Bill. Wow. Using non-nullable (a sane language default) pointers in Zig is liberating experience. And it's still as low level as in C but instead of ship-and-pray you could state your intention with a type system.
      • uecker 4mo ago
        Is it? I program in C a lot, and null pointer dereferences are not really an issue in my experience. And any option type (which you could also have in C) does not really change the fundamental problem that you have some exceptional state you need to handle at some point and if this is happens at a point where this is not expected, this blows up - also in other languages. I also once believe that complex type systems are the answer, but over time I realized this is not really true.
        • bvrmn 4mo ago
          Yes it is. 1) Most of pointers in real apps are non-nullable and it's nice to have enforcement from a compiler. 2) Good compilers verify you actually check nullable (optional) values have a corresponding check. In particular Zig literally forces you to unwrap value, so no unexpected state. It's a really amazing QoL. And no, optionality doesn't make type system any harder. Also C lacks alignment enforcement on type level and it's a real footgun which Zig also fixed. Zig has many warts but this part (optionality, alignment and slices) makes a big difference comparing to C without Rust/C++ level of type acrobatics. > I also once believe that complex type systems are the answer, but over time I realized this is not really true. It's suboptimal decision, you load your brain with stuff compiler should resolve for you. Edit: ahah, just noticed your nick. Really appreciate your work on C improvements. Please ignore my yapping :) I literally know nothing comparing to you.
          • uecker 4mo ago
            My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. In any case, I wonder what you think about my experimental maybe type? https://godbolt.org/z/MTdj81841 https://godbolt.org/z/MTdj81841
            • bvrmn 4mo ago
              I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.
              • uecker 4mo ago
                Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)
                • 4mo ago
  • saghm 4mo ago
    I don't really consider Go a modern language anyhow. It's modern compared to C, but then again, so is Java, and it came out like three decades ago.