Hacker News Reader

Comment by mietek | Hacker News Reader

So, Go has message passing. Just like Erlang, since 1986.

Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake.

But it's not enough to scorn the industry; Go's designers also look down their noses at academia.

A modern, ML-derived static type system? Generics, which would enable the unwashed mashes to write their own `append`? Ain't nobody got time for that — wait, what? Oh, Rust does?

Go's tooling is fantastic, and its pragmatism is commendable, but ignoring the last 30 years of programming language research is not.

View on HN

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.

> 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+Referenc...

2. http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-prin...

3. http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf

> 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.

> 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.

> 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.

> 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.

> 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.

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_matchin...

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.

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.

> 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.

Option types need no type system support beyond having option types at all. Think of an option type as a container. It's either empty, or it has a single element inside it.

You can manipulate your container by checking if it's empty, getting the value out, manipulating the value and putting the value in a new collection. That's the basic low-level primitives of interacting with an option type.

And you can also use higher-order operations, e.g. map over the collection which will only "do things" if there's a value and will just return an empty collection if there isn't. These are the higher-level combinators on option types. They require no type system complexity outside of having option types in the first place.

Yes. Also, these low-level primitives already exist in Go, as support for pointers, or references. The missing bit is requiring references to be explicitly annotated as nullable or non-nullable.

I disagree with you on the relative complexity of type systems, and, as someone passionate about my craft, I despair Go is merely good not great, due to what appears to be uninformed design decisions.

You may prefer to write in Go, but you don't work in a vacuum. Your creation is out there, gaining mindshare, and propagating mistakes made half a century ago. As a language designer, you have the power to shape human thought for years to come, and the responsibility to remain intellectually honest. This is the meaning of Hoare's apology. He didn't know better. You have no such excuse.

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.

> 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.

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.

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.

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.

"has to" is a bit strong. The standard assumption is that pointer arguments should be set (or the function is documented otherwise), and the responsibility is left with the caller. It just bubbles out from there.

Yes, this is the way things have been done since 1965. It sounds simple enough, but as it turns out, in complex systems, this is a common cause of defects.

Programmers forget to check things all the time. Assumptions made in different areas of the code, by different programmers, at different times, do not always hold.

Fortunately, computers are good at remembering to check things. We just need to allow them to do so.

The main Go authors come from a C background, and they despise C++ and Java. It seems that those languages are their main experience, and hence, Go does not look too different from them.

Go was originally presented as a "systems" programming language, and as a C++ replacement. It failed to attract C++ and other systems programmers, while attracting Python and Ruby coders. In retrospect, it seems to make sense.

I suspect the reason adding generics is hard in Go is a due to its weird composition system (they loathe object hierarchies too, remember?)

I concur, that we should be using and developing languages that have strong, expressive type systems. Furthermore, these languages are not "complex" to use or understand. I really admire what the Rust people are doing. They are writing a browser engine while developing the language, so they can continually evaluate their design choices, and if needed, change things as they go.

Go looks like it has been designed into a corner, but it is too late to back up now. The main driving force it has is that it has Google as a brand name behind it, unfortunately. Otherwise, it most likely wouldn't have gone anywhere.

> Go looks like it has been designed into a corner, but it is too late to back up now.

Not really. We had years of experience with Go—and made many changes—before we stabilized the spec with Go 1. We are happy with the major decisions we have made so far, as are a lot of Go users. Of course there are minor things we would change if given the chance today, but the basics of the type system and the presence of nil pointers are not among them.

The reason generics is hard is because we want to find a way of doing it without losing the feel of the language we have right now (which we quite like, thanks).

The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.

I haven't seen him comment on generics in languages other than C, C++ and Java.