4 ms·

Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency mode

by enneff 13y ago

Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. > it includes null references, also known as Hoare's Billion Dollar Mistake. The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true. > Ain't nobody got time for that — wait, what? Oh, Rust does? Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust. > ignoring the last 30 years of programming language research is not. This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language. Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives. And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.

mietek 13y ago
> Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. I've already mentioned Go doesn't have per-process heaps, and I consider this a step backwards from shared-nothing message passing. I don't understand how can you argue that facilitating the threads-and-locks model leads to "simple code that is obviously correct". Writing correct multithreaded code is widely recognized to be difficult. > The very notion of null references being inherently bad is highly contentious. If by this you mean people keep[1] pointing[2] out[3] the problems with nulls, and other people keep ignoring them, then I fully agree. Otherwise, please direct me to a discussion offering a pro-null argument. For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. Alternatively, in a language with option types, only values explicitly marked as optional must be checked, and forgotten checks are pointed out by the compiler. Less code, more safety. Tell me again, how does allowing null references lead to "simple code that is obviously correct"? > If you don't have null pointers or [do have] generics, then you need a more complex type system. Certainly. More complexity for the language implementers; less complexity for the language users. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-prin... 3. http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf
- enneff 13y ago
  > For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. If you don't have null pointers then you need to push the responsibility for checking for initialization somewhere. You seem to be advocating that place is in the type system. That's fine, but you can't say it wouldn't make the type system more complex. I see more Go code than probably anyone in the world, and I don't see anyone suffering from the scourge of null pointers, however bad people say they are. I think in certain contexts they can be problematic (SQL is a good example), but the concept of "nil" in Go is quite useful and easy to understand. For instance, unlike C++ it is quite valid to call a method on a nil receiver. > Tell me again, how does allowing null references lead to "simple code that is obviously correct"? It's a tradeoff. You get a simpler type system in exchange for null pointers. > More complexity for the language implementers; less complexity for the language users. No, not just for the implementers. For the users too.
  - mietek 13y ago
    > No, not just for the implementers. For the users too. You haven't bothered to address option types. This sort of unqualified assertion may lead people to believe Go's questionable design decisions were, in fact, made out of ignorance. A language with null references is exactly like a language with option types, where every reference value is by default optional. Removing this default does not increase complexity for the user. Conversely, it allows the user to write less code and enjoy more safety, which is clearly a complexity decrease.
    - 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.

by enneff 13y ago

mietek 13y ago

> Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. I've already mentioned Go doesn't have per-process heaps, and I consider this a step backwards from shared-nothing message passing. I don't understand how can you argue that facilitating the threads-and-locks model leads to "simple code that is obviously correct". Writing correct multithreaded code is widely recognized to be difficult. > The very notion of null references being inherently bad is highly contentious. If by this you mean people keep[1] pointing[2] out[3] the problems with nulls, and other people keep ignoring them, then I fully agree. Otherwise, please direct me to a discussion offering a pro-null argument. For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. Alternatively, in a language with option types, only values explicitly marked as optional must be checked, and forgotten checks are pointed out by the compiler. Less code, more safety. Tell me again, how does allowing null references lead to "simple code that is obviously correct"? > If you don't have null pointers or [do have] generics, then you need a more complex type system. Certainly. More complexity for the language implementers; less complexity for the language users. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-prin... 3. http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf

enneff 13y ago
> For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. If you don't have null pointers then you need to push the responsibility for checking for initialization somewhere. You seem to be advocating that place is in the type system. That's fine, but you can't say it wouldn't make the type system more complex. I see more Go code than probably anyone in the world, and I don't see anyone suffering from the scourge of null pointers, however bad people say they are. I think in certain contexts they can be problematic (SQL is a good example), but the concept of "nil" in Go is quite useful and easy to understand. For instance, unlike C++ it is quite valid to call a method on a nil receiver. > Tell me again, how does allowing null references lead to "simple code that is obviously correct"? It's a tradeoff. You get a simpler type system in exchange for null pointers. > More complexity for the language implementers; less complexity for the language users. No, not just for the implementers. For the users too.
- mietek 13y ago
  > No, not just for the implementers. For the users too. You haven't bothered to address option types. This sort of unqualified assertion may lead people to believe Go's questionable design decisions were, in fact, made out of ignorance. A language with null references is exactly like a language with option types, where every reference value is by default optional. Removing this default does not increase complexity for the user. Conversely, it allows the user to write less code and enjoy more safety, which is clearly a complexity decrease.
  - 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.