Hacker News Reader

Comment by signa11 | Hacker News Reader

imho, go, afaik, is designed to cleanly express concurrency primitives in the context of a single system, and doesn't do 'fault-tolerance' in the erlang sense of 'you need >1 machine to be fault-tolerant'. with that lens, it is clear that the optimal way to do concurrency is with shared state, but that gets exported out via channels and go-routines etc.

also, can someone please explain the issues around 'nil' ? i fail to appreciate author's concern about those...

View on HN

> also, can someone please explain the issues around 'nil' ? i fail to appreciate author's concern about those..

The question can be thought of as two parts:

1) Whether nil should be a base value for objects. If something points to type t, should that be allowed to be nil. It is obvious that it should if coming from C/C++/Python, not so obvious if coming from Haskell for example.

2) Should the lack of objects, or should error conditions be represented by nil. Say lack of a an object in a map is indicated by returning nil. Should it throw an an exception instead? Now, go doesn't have exceptions so it needs something like this perhaps. Or maybe panic should happen.

To expand on 1). If you are coming from Haskell (or any strong typed language) the thinking is, you are already paying the price for static checking, strong types, compilation step etc. It would be nice to have explicit non-nil types. You can say this function accepts a reference to this object and this cannot be nil. During compile time the typechecker/compiler will do a more rigorous analysis based on that, and barf out an error then instead of during production.

Like in Haskell you can explicitly say something may be nil (Nothing):

       data Maybe a = Nothing | Just a

I don't personally lean one way or another here. I just don't have a strong opinion either way. I understand the trade-off. But this is how I interpret what the author means by his issue with 'nil'. Hopefully this helps.

Golang maps do not return nil for missing values of maps. Referencing a missing value in map returns the zero value for the value type, which for int is 0, for string is the empty string "", bools are false, and so forth. Golang also has the two-return-value form of map reference:

  value, exists = myMap[42]

For 1), modern C++ style generally frowns upon NULL pointers, preferring to use references, which are guaranteed to be non-NULL.

There is no such guarantee, a NULL reference can be created although it does require a little more effort than creating a null pointer.

However, null is just a special case of "invalid" pointer (e.g. point to freed memory), and it's very easy to create an invalid reference, e.g. take a reference into a vector and then push a pile more elements onto it, causing the vector to reallocate and move in memory, invalidating the reference.

You're talking about undefined behavior. There's no such thing as a null reference according to the C++ language specification.

So? It's still possible to create one. (There's no such thing as dereferencing an invalid pointer according to the standard, but that still happens.)

If it takes undefined behavior to create a "null reference" then by definition it's not possible to create one and still have a well-defined program. That is, you have bigger problems than "null references" to worry about.

There is no such guarantee. I fixed more than one bug of invalid references.

My understanding is that it is impossible to have a NULL reference. Can you show us some code that ends up with a NULL reference? I'd be curious to see how that can be done!

Dereference a NULL pointer and use the result to initialize a reference. Sure, it's undefined behavior, but so are all the problems that result from NULL pointers, and in practice it doesn't crash until you "dereference" the reference by looking at the value, so it's probably as hard to track down as a NULL pointer crash.

I'll leave it as an excercise to you. Promise me that I don't have to maintain your C++ code until you completed it.

> Hopefully this helps.

yes, it does. thank you for your kind explanation.

> also, can someone please explain the issues around 'nil' ? i fail to appreciate author's concern about those...

Take it from the guy who _invented_ nil: http://qconlondon.com/london-2009/presentation/Null+Referenc...

It should be noted that nil in Go is not quite[1] the same as null in C though. For example, if a method defines the return type as a value (say, a string), you cannot validly return a nil (compile error).

  [1]: http://blog.denevell.org/golang-null-nil.html

Er… similar code in C:

    struct foo bar () {
        return NULL;
    }

is a compilation error as well… (granted it's not an error for strings because C has no strings per-se)

  > (granted it's not an error for strings because C has no strings per-se)

That was kind of the entire point though.

Say what? Your statement is that Go's nil is different than C's null. As demonstrated, it is not, C's null is for pointers and Go's nil is also for pointers.

The difference is that Go has a value-type string and C does not, but that is only a parenthesised aside in your original comment (as an example of Go value types), nowhere near "the point" let alone "the entire point".

Reply on news.ycombinator.com