Some time ago I posted about Go vs. Python with regard to delimiters. I now have another reason to prefer Python to Go: Go's error handling (hat tip: Hacker News).

To briefly see the issue, consider the following snippet of idiomatic Python:

with open(filename, 'r') as f:
    # do something with f

What happens if the open call fails? An exception is thrown. If we want to deal with it, we wrap the call in a try/except block:

try:
    with open(filename, 'r') as f:
        # do something with f
except IOError:
    # handle failure to open the file

Now consider the corresponding snippet of Go, taken from the blog post linked to above:

f, err := os.Open(filename)
if err != nil {
    // handle failure to open the file
}
// do something with f

Two things jump out at me by comparing the above snippets (leaving aside all the stuff about delimiters, etc. that I ranted about last time). First, if the file open fails, Python guarantees that the "do something with f" code will not execute; Go depends on the programmer putting something in the "handle failure to open file" code that does that. Of course, fixing that particular wart is easy:

f, err := os.Open(filename)
if err != nil {
    // handle failure to open the file
} else {
    // do something with f
}

Which of course begs the question, why didn't the blog post write it that way? Perhaps because the poster expected the "do something with f" code to test for a valid file object? In other words, they really intended to write this:

f, err := os.Open(filename)
if err != nil {
    // handle failure to open the file
}
if f != nil {
    // do something with f
}

(I'm assuming that testing for a non-nil f is sufficient; if it isn't, changing the if statement appropriately is straightforward.) In Python, no such testing of f is required:; Python guarantees that inside the with statement block (the "do something with f" code), f is a valid open file object. It can make that guarantee, of course, because it can guarantee that the block will not execute if the file open fails. In other words, Go forces the programmer to do things by hand that Python takes care of automatically, and since those things are, at least IMHO, "boilerplate" things that programmers shouldn't have to worry about, Python's method is preferable.

This by itself may not be a huge issue; but now consider the second thing that jumped out at me. In Python, I only need to wrap the with block in a try/except block if I want to handle the failure condition in that particular section of code. Otherwise, I just let the exception propagate until something catches it. This is, of course, the whole point of having exceptions as your error handling mechanism: it uncouples handling of errors from handling of normal conditions. Some people, apparently including the Go designers, consider this to be Very Bad Juju, and as you can see, in Go you have no choice about where you handle errors; you have to test for them and handle them locally, whether you want to or not.

Why might you not want to? Suppose I'm writing a library to open and parse a particular type of file. This library might be used by a variety of applications; some might be end-user apps for editing the file, while others might be server-side apps that just want a parsed object they can use to read attributes from. The way that a failure to open the file should be handled is very different for these two types of apps: the end-user app needs to display a message to the user (at least if it wants to be usable), while the server-side app probably should just log the error and go on, or perhaps send an urgent page to a sysadmin.

If I'm writing this library in Python, handling all this is simple, because error handling is uncoupled from normal functionality. Each app's code simply catches the IOError exception in the appropriate place and deals with it. In Go, what do I do? Either my library gets overgrown with error-handling code for all manner of possible use cases, even though I know far less about those use cases than the app writers do, or else I have to put together an elaborate system of callbacks, plugins, or what-have-you to deal with what is fundamentally a simple problem.

So once again, while it's great that people are trying new things with programming languages, I'm still sticking with Python.

I recently came across this from Jamie Zawinski, and one of his gripes with Firefox struck a huge chord with me:

The Firefox UI is a moving target. It is under constant "improvement", which means "change" which means every few months I'm forced to upgrade it and shit has moved around and I need to re-learn how to do a task that I was happily doing before.

Read more...

A while back I explained why I use Python, not Lisp. However, after reading this review of Go, I realized that I left out something important, something that sets Python apart from pretty much every other language out there, and certainly from every "C-oid" language, which is all that the author of the review seems able to find himself wishing for.

Read more...

Cary Sherman, the CEO of the RIAA, is upset. He says those mean and nasty Internet companies shut down SOPA and PIPA by spreading misinformation and claiming it was fact. Well, after reading his recent op-ed in the New York Times, I will certainly concede that Mr. Sherman ought to know about that sort of thing, since he is evidently an expert at it. Just for fun, I thought I would post some examples.

Read more...

This is just a quick update to my previous posts on SOPA to collect a few more links of interest.

Read more...

I thought I was done with this topic for now, but I can't help adding one more quick post, because it now appears that it isn't just media companies who want to put a stranglehold on the Internet. Chanel is getting in on the act.

Read more...

This is just a quick update to yesterday's post. According to Ars Technica,

Last Thursday, the European Parliament adopted a resolution ahead of a forthcoming summit between Europe and the United States. It included a section on "the need to protect the integrity of the global Internet and freedom of communication by refraining from unilateral measures to revoke IP addresses or domain names."

That provision was added at the urging of the civil liberties organization European Digital Rights (EDRi). In a presentation to the Parliament's Civil Liberties Committee, EDRi's Joe McNamee noted that "the United States has, up until recently, never sought to exploit its theoretical jurisdiction over the companies and infrastructure that are at the core of the Internet."

Read more...

I've posted twice now about the Protect IP Act, or SOPA (the former is the Senate version, the latter is the House version), which is the latest attempt on the part of big media companies to put a stranglehold on the Internet.

Read more...

Having spent enough time using all three of the major OS's to have a decent understanding of their flaws, it's easy to explain why I use Linux whenever I have a choice: its flaws are much easier to manage.

Read more...

The New York Times, which is certainly a bastion of the liberal arts types if anywhere is, has been running a debate about law school that is similar to the one about college in general that I discussed in my post a couple of weeks ago on the two cultures.

Read more...