Python & Go

Duncan Booth duncan.booth at invalid.invalid
Thu Nov 12 10:55:52 CET 2009


Michele Simionato <michele.simionato at gmail.com> wrote:

> I forgot to post a link to a nice analysis of Go:
> http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php
> 
Thanks for that link. I think it pretty well agrees with my first 
impressions of Go: there are some nice bits but there are also some bits 
they really should be so embarassed that they even considered.

The lack of any kind of error handling, whether exceptions or anything else 
is, I think, a killer. When you access a value out of a map you have a 
choice of syntax: one way gives you a boolean flag you can test to see 
whether or not the item was in the map, the other either gives you the 
value or crashes the program (yes, the documentation actually says 
'crash'). Both of these are wrong: the flag is wrong because it forces you 
to handle every lookup error immediately and at the same place in the code; 
the crash is wrong for obvious reasons.

The lack of inheritance is a bit weird, so far as I can tell you can have 
what is effectively a base class providing some concrete implementation but 
there are no virtual methods so no way to override anything.

What that article didn't mention, and what is possibly Go's real strong 
point is that it has built-in support for parallel processing. Again though 
the implementation looks weak: any attempt to read from a channel is either 
non-blocking or blocks forever. I guess you can probably implement timeouts 
by using a select to read from multiple channels, but as with accessing 
values from a map it doesn't sound like it will scale well to producing 
robust applications.

It has too many special cases: a lot of the builtin types can exist only as 
builtin types: if they weren't part of the language you couldn't implement 
an equivalent. e.g. A map has a key and value. The key can be any type 
which implements equality, but you can't implement equality tests for your 
own types so you cannot define additional key types.

-- 
Duncan Booth http://kupuguy.blogspot.com



More information about the Python-list mailing list