The difference is that the Go style can provide a sane fallback, which the client code can IGNORE.

For instance, the built in map type returns a pair of values, the first is the actual matched value, the 2nd a boolean. If a key is not found the value is set to the type's zero-value, and the boolean as false. So for a map of string->integer, instead of throwing a NoSuchKey exception or something, just returns 0,false. So there's no mandatory ceremony when you don't care.

Sure, and you've got to check the boolean if you care. Which is almost the same as the (gasp) Java code:

    // don't care
    value = map.get(key);
    do bleh

    // care
    if (map.containsKey(key)) {
      do blah
    } else {
      value = map.get(key);
      do bleh
    }

To be clear, there are two kinds of errors:

1. The code is screwed up. Java runtime exception, log and hope someone is paying attention to the logs.

2. The world is screwed up. Java checked exception, catch and return a nice message to the user.

It appears your code will find the value _twice_. That is less than ideal and not equivalent at all.

If an assumption can be made that you won't put null values into the map then it can be rewritten where it doesn't need to do the check described above:

  value = map.get(key);
  if (null == value) {
    // Handle no value in the map
  }

Any class correctly implementing Map in Java won't throw an exception if there is no value for an input key (http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#...) and some don't allow you to put null values in to begin with (http://docs.oracle.com/javase/6/docs/api/java/util/Hashtable...).

I think one of the points of the OP's article is that in Go you don't have to code like you've done here, where a single return value means one of two things (in your example: value in the map, or special reserved value that indicates the key wasn't found in the map). Go is cleaner, even if it's just a small improvement.

The argument used to be how "Go got exceptions right".

Now, it appears that the argument is about how to save a trivial amount of work for the CPU, when it's unclear whether this is a bottleneck, or whether the JIT can optimize away the two calls, or, in the remaining 1% of the cases, using the null idiom makes this a non-issue.

All at the cost of spending 1 of my 7 brain registers to handle "mandatory ceremony" of adding a _ to every map.get call, regardless of whether I actually know that the given map access should never see an unmapped key, which is the vast majority of cases in my day-to-day coding experience.

At the very best, the argument is about "multiple return values are useful in some cases". But tread carefully, lest every caller has to worry about useless return values.

Actually I was struck the other way: this appears to be basically unchecked exceptions. Functions return errors, which you can check or not if you like. The only difference is that the "exception" doesn't unwind the stack any more than the function call.

So this guy goes on about how bad unchecked exceptions are, then waxes poetic about Go's, erm, unchecked exceptions.

To add to the weirdness, he seems to think that most people like checked exceptions, when in fact he appears to be very much in the minority.

No library in a language with exceptions as they're normally used would do that. Exceptions are for exceptional cases. You use the method that throws only if it is a programming error for it to throw; and you do not, as a general rule, catch exceptions. See eg Dictionary.TryGetValue in .net. Your argument is against a straw man, IMHO.

So are you saying python is not a sane language?

    >>> a = {}
    >>> a['foo']
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    KeyError: 'foo'

Python uses Exceptions for unexceptional cases, yes, like loop termination. It's one of the only languages to do it.

It is widely agreed that this behavior is a hack in Python. It is not a role model.