3 ms·

I would guess null is the default because many of us start out with languages like C or Java. I've seen some interns have FP experience with Haskell, but it ten

by onei 5y ago

I would guess null is the default because many of us start out with languages like C or Java. I've seen some interns have FP experience with Haskell, but it tends to be a single module and they often don't appreciate the nuance and FP is still not particularly mainstream in industry. More generally, I don't think many programmers get to see the better way because they're not exposed to it. I can rhapsodise about Rust, but I doubt my company is going to buy into it because they already picked Go.

cies 5y ago
> I would guess null is the default because many of us start out with languages like C or Java. Go is not a language that "just happened" (what could be said of JS and PHP). Go is designed. Designed by heavyweight language designers (from Wikipedia): Robert Griesemer, Rob Pike and Ken Thompson. These people knew of Haskell, type systems, and the merits of type safety. I would expect them to know of "billion dollar mistake[1]" that is null. But sadly Go still carries on with the mistake. I too care more about null-safety and proper sum types (in combination with nice switch/match statements and/or pattern matching) than generics. In the Elm language I found an experience that not having generics is perfectly okay (just a little annoying sometimes). I find "not null safe languages" not okay nowadays, and I hold this opinion since before Go's first appearance (2009). I really wonder how the designers came to this decision. I'm afraid this mistake can never be fixed, as null checks are already idiomatic Go. Java also could not fix it (which may be one of the main reasons behind Kotlin). Maybe the best thing we can hope for is Kotlin kind of language for Go (question marks after types to indicate nullability). It's just sad. [1]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...
- chrisseaton 5y ago
  > I would expect them to know of "billion dollar mistake[1]" that is null. But sadly they had not. What makes you think that they didn’t know about it, rather than that they did know but decided they weren’t interested in the trade offs for this particular new language.
  - cies 5y ago
    I misworded what I thought. I think they knew but have no clue why they went ahead with the mistake non the less.
- 5e92cb50239222b 5y ago
  >Java also could not fix it (which may be one of the main reasons behind Kotlin). C# added some null-safety features despite having a 20-something year baggage of legacy code. While it might not be the perfect solution (these checks work only at compile time and you can enable them per-file), I find that they work great for new projects. You have to be extra careful at boundaries (interfaces with third-party libraries which have not added ? annotations yet, API calls, and so on), but they save a lot of headache inside your own code.
  - cies 5y ago
    Cool. It's a bit like what Kotlin did. Yet after some experience with Kotlin I found it is not perfect. "You have to be extra careful at boundaries" exactly, with Kotlin too. The question mark is the best thing if you have not build your language with null safety to start with. Please look at Elm for a good example of what real null safety looks like. With Go they had to change to do the right thing from the start. I really wonder why they didnt.
    - lazulicurio 5y ago
      Also worth noting that Java may be able to fix it in the future after Valhalla drops (and this may mean better implementation for JVM-based languages too).
      - cies 5y ago
        I sure hope so. Not holding my breath though. :)

by onei 5y ago

cies 5y ago

> I would guess null is the default because many of us start out with languages like C or Java. Go is not a language that "just happened" (what could be said of JS and PHP). Go is designed. Designed by heavyweight language designers (from Wikipedia): Robert Griesemer, Rob Pike and Ken Thompson. These people knew of Haskell, type systems, and the merits of type safety. I would expect them to know of "billion dollar mistake[1]" that is null. But sadly Go still carries on with the mistake. I too care more about null-safety and proper sum types (in combination with nice switch/match statements and/or pattern matching) than generics. In the Elm language I found an experience that not having generics is perfectly okay (just a little annoying sometimes). I find "not null safe languages" not okay nowadays, and I hold this opinion since before Go's first appearance (2009). I really wonder how the designers came to this decision. I'm afraid this mistake can never be fixed, as null checks are already idiomatic Go. Java also could not fix it (which may be one of the main reasons behind Kotlin). Maybe the best thing we can hope for is Kotlin kind of language for Go (question marks after types to indicate nullability). It's just sad. [1]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...

chrisseaton 5y ago
> I would expect them to know of "billion dollar mistake[1]" that is null. But sadly they had not. What makes you think that they didn’t know about it, rather than that they did know but decided they weren’t interested in the trade offs for this particular new language.
- cies 5y ago
  I misworded what I thought. I think they knew but have no clue why they went ahead with the mistake non the less.
5e92cb50239222b 5y ago
>Java also could not fix it (which may be one of the main reasons behind Kotlin). C# added some null-safety features despite having a 20-something year baggage of legacy code. While it might not be the perfect solution (these checks work only at compile time and you can enable them per-file), I find that they work great for new projects. You have to be extra careful at boundaries (interfaces with third-party libraries which have not added ? annotations yet, API calls, and so on), but they save a lot of headache inside your own code.
- cies 5y ago
  Cool. It's a bit like what Kotlin did. Yet after some experience with Kotlin I found it is not perfect. "You have to be extra careful at boundaries" exactly, with Kotlin too. The question mark is the best thing if you have not build your language with null safety to start with. Please look at Elm for a good example of what real null safety looks like. With Go they had to change to do the right thing from the start. I really wonder why they didnt.
  - lazulicurio 5y ago
    Also worth noting that Java may be able to fix it in the future after Valhalla drops (and this may mean better implementation for JVM-based languages too).
    - cies 5y ago
      I sure hope so. Not holding my breath though. :)