17 ms·

> A language with null references is exactly like a language with option types, where every reference value is by default optional. Yes. > Removing this defau

by enneff 13y ago

> A language with null references is exactly like a language with option types, where every reference value is by default optional. Yes. > Removing this default does not increase complexity for the user. Yes, it does. They need to be aware of the semantics of the option mechanism, how to specify whether a type is optional, and when that is appropriate. They must also perform checks when converting values from optional to non-optional types. In Go the choice is made for you: reference types may be nil.

mietek 13y ago
> They need to be aware of the semantics of the option mechanism, how to specify whether a type is optional, and when that is appropriate. Being aware of the semantics of the option mechanism is exactly like being aware of the semantics of null references. You've just agreed one is like the other with a default. Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment. Comments aren't usually checked by the compiler. Knowing whether it's appropriate for a value to be optional is exactly like knowing whether it's appropriate for a reference to be null. However, once a value is determined to exist, subsequent code can assume the value is non-optional, avoiding subsequent checks with no decrease in safety. Less complexity. > They must also perform checks when converting values from non-optional to optional types. Surely you mean the other way around? Checking whether an optional value exists is exactly like checking whether a reference is not null. However, fewer checks are necessary. Less complexity.
- enneff 13y ago
  > Surely you mean the other way around? Yes, I had it backwards. Corrected. > Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment. Is it? I agree there's definite virtue in having this property checked by the compiler, but I think you and I will have to disagree on the notion of complexity here.
  - azth 13y ago
    The beauty of Option types is that they are mostly used as return types. Most function arguments are non-nullable pointers or references; only ones that might be None are passed as options. This makes reasoning about code much easier. I just look at the function signature, and I know the types of arguments it expects. I also don't have to litter the beginning of each function call with if !null checks to each reference parameter. > They must also perform checks when converting values from optional to non-optional types. There are multiple ways to manipulate option type variables. The following comment from a Redditor sums it up very nicely: "What is interesting is that (coming from scala and haskell) you almost never pattern-match on option types. The power of option, imho, is that you don't have to care whether it is Some or None, you write the same code regardless. If you are pattern-matching the whole time, you haven't gained all that much over checking for nil/null. Option is a container, and we can use my_var.chain(...) and my_var.map(...) to update the things in the container. And the joy of it is that these methods will automatically do the right thing, with repect to Some/None, so you can string a bunch of these calls together, and if my_var is Some(...) is will apply all of the specified functions. If it is None, it will remain None." source: http://www.reddit.com/r/rust/comments/1ewrhz/pattern_matching_and_the_option_type/ http://www.reddit.com/r/rust/comments/1ewrhz/pattern_matchin...
    - enneff 13y ago
      What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported. For option types to work well in Go you would need to add more support to the type system. But we don't want a more complex type system. That's a tradeoff we made. Again, I'm not really sure why people keep getting bent out of shape about this. Haskell, Scala, and Rust exist for people who want to write that kind of code. I prefer to write Go code.
      - azth 13y ago
        I can't speak about the others. However, I feel that we have reached an unfortunate state in the industry when a sub-par technology starts to get picked up because of brand names, and not on inherent merits.
3d3mon 13y ago
Null references do make reading code more complex for the user since every function call must be prefaced with a null check. If I make a function call in every line of my code adding all the null checks would easily double my line count, burying my code in Java-like verbosity (ok not that much but you get the idea). I suppose a good IDE could help with this if option types remain unavailable. Another common complaint with null references is that there is no compile-time type safety that you get with option types. The go team could mitigate this by having the compiler check for possible null references that may not have been caught and emit warnings or refuse to compile.
- enneff 13y ago
  > Null references do make reading code more complex for the user since every function call must be prefaced with a null check. Well, the Go code I see doesn't look like this, so that can't be right.
  - azth 13y ago
    So "right" Go code ignores checking references that can be null so that it can blow up at run time? That can't be safe.
    - enneff 13y ago
      No, it's just that's not how it works. For instance, s, err := server.New() if err != nil { // handle error } s.Foo() You're not going to check that s != nil before calling s.Foo, even though s is probably a *server.Server and could be nil. But it won't be, if the New function is correct. Yes, the compiler doesn't guarantee that New gives you a non-nil pointer, but it also doesn't guarantee a lot of things about the behavior of the program.
      - azth 13y ago
        I was mainly referring to function arguments. Any function that takes a pointer type has to have null checks at the beginning, since any of the pointer arguments may be null.
deleted 13y ago
[deleted]

by enneff 13y ago

mietek 13y ago

> They need to be aware of the semantics of the option mechanism, how to specify whether a type is optional, and when that is appropriate. Being aware of the semantics of the option mechanism is exactly like being aware of the semantics of null references. You've just agreed one is like the other with a default. Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment. Comments aren't usually checked by the compiler. Knowing whether it's appropriate for a value to be optional is exactly like knowing whether it's appropriate for a reference to be null. However, once a value is determined to exist, subsequent code can assume the value is non-optional, avoiding subsequent checks with no decrease in safety. Less complexity. > They must also perform checks when converting values from non-optional to optional types. Surely you mean the other way around? Checking whether an optional value exists is exactly like checking whether a reference is not null. However, fewer checks are necessary. Less complexity.

enneff 13y ago
> Surely you mean the other way around? Yes, I had it backwards. Corrected. > Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment. Is it? I agree there's definite virtue in having this property checked by the compiler, but I think you and I will have to disagree on the notion of complexity here.
- azth 13y ago
  The beauty of Option types is that they are mostly used as return types. Most function arguments are non-nullable pointers or references; only ones that might be None are passed as options. This makes reasoning about code much easier. I just look at the function signature, and I know the types of arguments it expects. I also don't have to litter the beginning of each function call with if !null checks to each reference parameter. > They must also perform checks when converting values from optional to non-optional types. There are multiple ways to manipulate option type variables. The following comment from a Redditor sums it up very nicely: "What is interesting is that (coming from scala and haskell) you almost never pattern-match on option types. The power of option, imho, is that you don't have to care whether it is Some or None, you write the same code regardless. If you are pattern-matching the whole time, you haven't gained all that much over checking for nil/null. Option is a container, and we can use my_var.chain(...) and my_var.map(...) to update the things in the container. And the joy of it is that these methods will automatically do the right thing, with repect to Some/None, so you can string a bunch of these calls together, and if my_var is Some(...) is will apply all of the specified functions. If it is None, it will remain None." source: http://www.reddit.com/r/rust/comments/1ewrhz/pattern_matching_and_the_option_type/ http://www.reddit.com/r/rust/comments/1ewrhz/pattern_matchin...
  - enneff 13y ago
    What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported. For option types to work well in Go you would need to add more support to the type system. But we don't want a more complex type system. That's a tradeoff we made. Again, I'm not really sure why people keep getting bent out of shape about this. Haskell, Scala, and Rust exist for people who want to write that kind of code. I prefer to write Go code.
    - azth 13y ago
      I can't speak about the others. However, I feel that we have reached an unfortunate state in the industry when a sub-par technology starts to get picked up because of brand names, and not on inherent merits.

3d3mon 13y ago

Null references do make reading code more complex for the user since every function call must be prefaced with a null check. If I make a function call in every line of my code adding all the null checks would easily double my line count, burying my code in Java-like verbosity (ok not that much but you get the idea). I suppose a good IDE could help with this if option types remain unavailable. Another common complaint with null references is that there is no compile-time type safety that you get with option types. The go team could mitigate this by having the compiler check for possible null references that may not have been caught and emit warnings or refuse to compile.

enneff 13y ago
> Null references do make reading code more complex for the user since every function call must be prefaced with a null check. Well, the Go code I see doesn't look like this, so that can't be right.
- azth 13y ago
  So "right" Go code ignores checking references that can be null so that it can blow up at run time? That can't be safe.
  - enneff 13y ago
    No, it's just that's not how it works. For instance, s, err := server.New() if err != nil { // handle error } s.Foo() You're not going to check that s != nil before calling s.Foo, even though s is probably a *server.Server and could be nil. But it won't be, if the New function is correct. Yes, the compiler doesn't guarantee that New gives you a non-nil pointer, but it also doesn't guarantee a lot of things about the behavior of the program.
    - azth 13y ago
      I was mainly referring to function arguments. Any function that takes a pointer type has to have null checks at the beginning, since any of the pointer arguments may be null.

deleted 13y ago

[deleted]