7 ms·

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

• paulddraper 1y ago
  Which one do you have in mind? Haskell?
  • zamadatix 1y ago
    Does it really matter which specific language?
    • paulddraper 1y ago
      The previous comment seemed to think the specific language mattered.
      • zamadatix 1y ago
        Do you mean Sytten's comment? I read that as joking we must be waiting for such safer languages to be invented otherwise we'd be using them, not as a push for a specific existing language itself. Humor can be hard to interpret in text though as it inherently requires trying to read into the message alone, but that you could replace "like Haskell?" with dozens of options via the same assumption is the original point/joke.
  • trealira 1y ago
    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.
  • jitl 1y ago
    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 https://github.com/borgo-lang/borgo) is a nil safe language that compiles to go, so is easily adoptable in existing Go systems.
    • paulddraper 1y ago
      Java Optional is just as safe as Kotlin Option (and predates it by a couple years). Scala, Kotlin, Java you just can’t get away from null :/
      • jitl 1y ago
        The important distinction for me with Kotlin's system is that the compiler guides developers to write null-safe code by default because it's built into the language itself. Whereas Optional in Java requires extra effort in instantiating Optional.of(...) all over the place. Java Optional is opt-in, similar to (but weaker than) SQL `NOT NULL` - easy to forget, rather than Kotlin opt-out. Even in safe languages like Rust, you can still introduce errors with the same semantics in application code as null pointer error: doing `some_optional.unwrap().someMethod()` will crash your program just as much as `someNullableObject.someMethod()` in Java.
      • tpm 1y ago
        Null-restricted types will be available soon I hope.
    • saltypal 1y ago
      I would only partially agree that Kotlin is "much safer." As one example, I just learned (by way of a nasty production app crash) that Kotlin chose to make all checked exceptions silently unchecked. Kind of a stunning own-goal for a language from 2010.
      • jitl 1y ago
        Oof, that feels like a blunder for Java interop, although I've never encountered use of checked exceptions in my admittedly limited Java experience. In everyday Kotlin code, I see either a sealed class or Result for cases where you'd find checked exceptions in Java, and otherwise normal unchecked exceptions from `require`, `check`, precondition assertions.
    • adsharma 1y ago
      Vlang is a much more active go variant with nil safety. But it gets a lot of hate in PL circles for reasons I don't completely understand.
  • morkalork 1y ago
    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?
  • supriyo-biswas 1y ago
    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.
• Unroasted6154 1y ago
  Good luck re-writing 25 years of C++ though.
  • tux3 1y ago
    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
    • Unroasted6154 1y ago
      You can do that for new binaries. For existing ones you can't really or you get in a worse place for a long time.
• madeofpalk 1y ago
  Thank god we have Go! /s