4 ms·

> I do still have a weird feeling of getting back to the stone age whenever i get a nil pointer panic though. i wish go devs could figure out a way of fixing th

> I do still have a weird feeling of getting back to the stone age whenever i get a nil pointer panic though. i wish go devs could figure out a way of fixing those last quirks without impacting the rest too much. Unfortunately fixing the "billion dollar mistake" as a retrofit is pretty much impossible without breaking backward compatibility. I see what they were trying for with nil and zero values, but IMO they should have introduced a "result" and "option" special type (or probably more Go-like would be separating nullable and non-nullable types via '?' like Dart did). If they did it like Dart, they could intro the concept without breaking backwards compatibility, wait X years until mostly adopted everywhere, and THEN break backwards compatibility by making it mandatory.

eru 4y ago
They should have introduced sum-types. Or in C term: tagged unions that are checked by the compiler. They did the opposite when they designed the language, with their 'multiple return values', which are like tuples but only allowed in one special position in the language. But as you already suggested, tuples are the exact opposite of the "result" type you'd want here.
- throwaway894345 4y ago
  I would have much preferred sum types to generics. I can live with rewriting min() or using for loops over iterators or writing my own linked list; it’s a lot harder to safely (and performantly) work with data that can have a fixed set of shapes.
  - eru 4y ago
    You know how Go had generics for a long time, but only for the language designers who got to use it in functions like `make` or data structures like `map` or `slice`. There didn't used to be any generics for users of the language. Similarly, Go has tuples, but only for the language designers who get to use them for multiple return values from a function. No tuples to be used elsewhere where users of the language might find them useful. Now, Go also has sum types. But, yet again, only for the language designers: they get to stick `nil` as one of the constructors (to use Haskell terminology) in their favourite data types, but you as a language user don't get to make new sum types. Another example is operator overloading: the designers get to overload eg arithmetic operators, but you don't get to do that. In contrast C++ even for all its other faults at least makes an attempt to hand you many of the tools the language designers get. (Though, I like Rust's and Haskell's approach here more.)
    - throwaway894345 3y ago
      No, the language designers use the same type system as everyone else. Yes, Go had a fixed set of generic data structures, but those were available to everyone. “Nil” does not a sum type make; it’s just the zero value for a reference type and the type-checker doesn’t check that you are handling nil and non-nil cases as a type-checker would do for sum types (if Go’s pointers are sum types, then integers and floats in any language are sum types as well). Go has never had operator overloading for the language designers or anyone else. The operators that the language designers use behave the same way as when users use them. I have a lot of respect for Rust, and I was a C++ developer in a past life, but most of the software I write these days cares a lot more about developer velocity than about eeking out every last bit of performance or correctness, and most of the time Go is the ideal candidate for those sorts of tradeoffs.
ilyt 4y ago
Pretty much; sum types would also allow for the other achilles heel of it to be fixed, the overly verbose error handling.

eru 4y ago

They should have introduced sum-types. Or in C term: tagged unions that are checked by the compiler. They did the opposite when they designed the language, with their 'multiple return values', which are like tuples but only allowed in one special position in the language. But as you already suggested, tuples are the exact opposite of the "result" type you'd want here.

throwaway894345 4y ago
I would have much preferred sum types to generics. I can live with rewriting min() or using for loops over iterators or writing my own linked list; it’s a lot harder to safely (and performantly) work with data that can have a fixed set of shapes.
- eru 4y ago
  You know how Go had generics for a long time, but only for the language designers who got to use it in functions like `make` or data structures like `map` or `slice`. There didn't used to be any generics for users of the language. Similarly, Go has tuples, but only for the language designers who get to use them for multiple return values from a function. No tuples to be used elsewhere where users of the language might find them useful. Now, Go also has sum types. But, yet again, only for the language designers: they get to stick `nil` as one of the constructors (to use Haskell terminology) in their favourite data types, but you as a language user don't get to make new sum types. Another example is operator overloading: the designers get to overload eg arithmetic operators, but you don't get to do that. In contrast C++ even for all its other faults at least makes an attempt to hand you many of the tools the language designers get. (Though, I like Rust's and Haskell's approach here more.)
  - throwaway894345 3y ago
    No, the language designers use the same type system as everyone else. Yes, Go had a fixed set of generic data structures, but those were available to everyone. “Nil” does not a sum type make; it’s just the zero value for a reference type and the type-checker doesn’t check that you are handling nil and non-nil cases as a type-checker would do for sum types (if Go’s pointers are sum types, then integers and floats in any language are sum types as well). Go has never had operator overloading for the language designers or anyone else. The operators that the language designers use behave the same way as when users use them. I have a lot of respect for Rust, and I was a C++ developer in a past life, but most of the software I write these days cares a lot more about developer velocity than about eeking out every last bit of performance or correctness, and most of the time Go is the ideal candidate for those sorts of tradeoffs.

ilyt 4y ago

Pretty much; sum types would also allow for the other achilles heel of it to be fixed, the overly verbose error handling.