As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling.

> (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)

So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".

I think it depends somewhat on the kind of software you're writing.

Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.

That also happens to be the intended distinction between Java's checked and unchecked exceptions.

the definition of "handle" widely varies, to the point of making the exercise near meaningless.

You mean outside of accidentally running into a nil, and having your program spontaneously abort?

Even worse, reliably testing for nil (`if (foo == nil)`) doesn't even save you because go's nils are typed. So `foo == nil` can actually return false even when foo is nil. Utter madness.

It is true that Go doesn't do as much as other languages to avoid nils. It's a small, unambitious language in some ways. (Like, it adds more typing than Python, not as much as rust or swift.)

    foo == nil

     package main

    import "fmt"

    type Foo struct{}

    func (f *Foo) Do() { fmt.Println("do the foo", f) }

    type Doer interface {
        Do()
    }

    func main() {
        var foo *Foo = nil
        fmt.Println(foo == nil) // true
        var doer Doer = foo
        fmt.Println(doer == nil) // false, because doer is (nil,Foo)
        doer.Do()                // prints "do the foo <nil>"
    }

That's because an interface is a (pointer,type) pair, so even if the pointer is nil, the type being non-nil will make the pair non-nil.

    var foo *Foo = nil
    var bar Bar  = foo
    
    foo == nil # true
    bar == nil # false

Null references have been referred to by Tony Hoare as his billion-dollar mistake. We should not be reintroducing mistakes of this level of magnitude, and worse, compounding on them, in new languages invented with fifty years of hindsight.

    func (o *Object) DoSomething() {
        if o == nil {
            fmt.Println("Nil implementation")
        }
        fmt.Println("Something with the members here")
    }

Go does not by any means solve the "billion-dollar mistake", and I'd still like to be able to put "non-nillable" on things, but it is less affected by it than C. (Which is damning with faint praise, certainly.)

I'll agree with the opinion that it can be confusing that an interface consists of two elements, the type and the value itself, and that the "== nil" check may not do what you initially expect, because the interface values are hidden below the surface of the abstraction the language provides. But it is not true to say that "the interface value is nil", because it factually isn't. To use psuedo-Go, since neither "Interface" nor the types are first-class values, Interface{ConcretePointerType, nil} does not and should not compare as equal to nil. There are values in memory corresponding to this interface value, and those values do not correspond to any interpretation of "nil" Go uses. We're talking about real numbers in real RAM here and a real specification of nil that corresponds to those real numbers in RAM; this is not a matter of opinion.

I don't know of any language that doesn't have a few dozen quirks of this sort buried in it. It can be pointed out as a legitimate criticism of the language, but it's not particularly a flaw relative to other languages. Either it's not possible to build a truly clean programming language that lacks this sort of quirk, or we're not very good at it.

Before replying to me with the language you believe lacks these quirks, please do me a favor and search for "$LANGUAGE quirk" and "$LANGUAGE gotcha" first, because that's the first thing I'm going to do. And it won't be a defense to me to explain how what you found is not really a quirk because you just have to properly understand the language, because that defense is true for this quirk of Go's too.

   a = nil
   b = a
   // => b == nil, right? but no.

i agree all languages end up with quirks like this (can't get everything right without really using the language, and by then it's too late!), and in fact go is low on the quirk level in my opinion.

the other one i really wish i could change is that

    for i, x := range foo

    But the fact that `foo == nil` can return false when foo is actually nil is indefensible. 

    …

    foo = nil
    bar = foo

    // this check may or may not evaluate as true
    if (bar == nil) {
       …
    }

The point being argued is that it doesn't matter that go defines this to be the case, the point being argued is that it's surprising, frustrating, and can lead to bugs. Particularly when `bar` starts off as a pointer to a struct, but later is refactored to be an interface type. Code that used to work still compiles, but now encounters a runtime nil panic.

In Go (as in most programming languages) it's not true that the assignment "a = b" implies that "b == foo => a == foo", if a and b are different types.

For example, this C code will print "nope":

    float b = 3.5;
    int a = b;
    printf(a==3.5 ? "yup" : "nope\n");

In practice I haven't encountered any refactoring bugs as you describe, though it is theoretically possible.

I personally don't see it as a big issue.

(In retrospect, Go could've help guide intuition better by using a new keyword like "unset" or something to test for the zero-value of interfaces, instead of overloading nil.)

While I haven't counted and compared, I suspect that in most programming languages, "a=b" being a non-error implies that either a and b are the same type and value, or that a and b are values that, if they are of different and comparable types, will compare equal.

There are certainly popular languages that do it the way you describe, but I don't think most languages do.

While this is true, in all of those other cases you have the benefit of compile-time type checking so cannot call a function on the wrong type.

With nil, you get runtime errors.