Python & Go
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:
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
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