Comment by Philpax

2 days ago

> Without the appropriate error handling, the null pointer caused the binary to crash.

We must be at the trillion dollar mistake by now, right?

If only we had a language that could prevent those /s

  • Good luck re-writing 25 years of C++ though.

    • It was Google's study that showed almost all bugs are in new code (and this was also the case of this incident)

      You don't need to rewrite everything to prevent the majority of new bugs, it's enough to protect new code and keep the battle tested stuff around

      1 reply →

  • Which one do you have in mind? Haskell?

    • Kotlin is very easily adoptable in existing Java systems and is much safer (although not guaranteed safe)

      Zig is fairly easy to adopt in existing C systems and is guaranteed null safe (although not use after free safe)

      Rust, although quite safe, bears a fairly high adoption cost as existing code often cannot be ported directly.

      Borgo (https://github.com/borgo-lang/borgo) is a nil safe language that compiles to go, so is easily adoptable in existing Go systems.

      11 replies →

    • I imagine the one they were thinking of was Rust, since it seems like that's more likely to be used where Go or C++ is, and it actually lets you use what are basically restricted pointers. But yeah, any language with an Option type that forces you to deal with the empty variant before you can use the data would have prevented it, including Haskell.

    • You can also just use a validation library of some sort such as go-playground/validator for Go and issues will sort themselves out by enforcing the loaded schema.

    • It's been a long time, but didn't google also have a whole Java library of data structures, utilities and annotations for avoiding using nulls at all?