39 ms·

It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Has

It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Haskell are not-nullable by default, and things that are nullable have an extra layer around them that must be dealt with. This is quite sensible.

enneff 15y ago
Go strikes a nice balance, IMO. Value types (booleans, numbers, strings, structs, arrays) cannot be null, while reference types (pointers, slices, maps, channels) may be null. Also, Go calls null 'nil', which is fitting since nil is the zero value of a reference type. (All variables are initialized to their zero value unless otherwise specified.)
- wanorris 15y ago
  .Net does the same thing (though strings and arrays are reference types, not value types), but it doesn't really solve the problem. If you write a function that performs an operation on a dictionary/hashtable/map/associative array, it would still be nice to be able to define it into the method signature that it's required (read: errors will be caught at compile time) to actually receive a reference to a dictionary. Or alternatively, that a null value is explicitly possible and that this should be accounted for. I agree with jganetsk and others -- after having used languages like Haskell where there are non-nullable types by default, every language that doesn't do this simply feels broken by comparison. It's sort of like going back to languages that require to you manually allocate memory and perform pointer arithmetic -- you can do it, but after years in the modern language of your choice that does it for you, it just seems unnecessary and basically wrong.
- smosher 15y ago
  That's the exact thing C does. The only thing Go does differently is put a ban on implicit conversions.

39 ms·

It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Has

by jganetsk 15y ago

enneff 15y ago
Go strikes a nice balance, IMO. Value types (booleans, numbers, strings, structs, arrays) cannot be null, while reference types (pointers, slices, maps, channels) may be null. Also, Go calls null 'nil', which is fitting since nil is the zero value of a reference type. (All variables are initialized to their zero value unless otherwise specified.)
- wanorris 15y ago
  .Net does the same thing (though strings and arrays are reference types, not value types), but it doesn't really solve the problem. If you write a function that performs an operation on a dictionary/hashtable/map/associative array, it would still be nice to be able to define it into the method signature that it's required (read: errors will be caught at compile time) to actually receive a reference to a dictionary. Or alternatively, that a null value is explicitly possible and that this should be accounted for. I agree with jganetsk and others -- after having used languages like Haskell where there are non-nullable types by default, every language that doesn't do this simply feels broken by comparison. It's sort of like going back to languages that require to you manually allocate memory and perform pointer arithmetic -- you can do it, but after years in the modern language of your choice that does it for you, it just seems unnecessary and basically wrong.
- smosher 15y ago
  That's the exact thing C does. The only thing Go does differently is put a ban on implicit conversions.