Another "Go is Python-like" article.

[Patrick Maupin]

On May 22, 5:00 am, Michele Simionato <michele.simion... at gmail.com>
wrote:
> On May 21, 4:20 pm, Grant Edwards <inva... at invalid.invalid> wrote:
>
> > What about Go, exactly, do people see as Python-like?
>
> The philosophy of keeping things simple. I find the concurrency
> mechanism quite Pythonic.

That's nice.

> Moreover Go interfaces are quite akin to Python duck typing, but
> better.

That's nice too.

> There also things which are quite different from Python e.g.
> the attitude towards exceptions.

That's a biggie.  One of the beautiful things about Python is how it
lets me incrementally deal with incompletely specified problems --
"here's some source data -- go do something useful with it".  The FAQ
discusses why the go language deliberately leaves out assert -- the
developers rightly view assert statements as problematic in achieving
5 nines in a server environment, and they (somewhat incorrectly IMO)
view them as problematic when testing things.

Looking at their rationale, it is appears that one or more of the
primary go developers had to deal way too often with people who
overuse and abuse exceptions, so they are reverting to an almost
childish "I'll fix their little red wagon!  When they have to use *my*
language, they won't be able to do that anymore!" kind of mentality.
Another possibility is that they viewed the complexity of exceptions
as interfering with their primary goals, and felt it necessary to
rationalize their absence after the fact.

For some kinds of programming, the lack of exceptions wouldn't keep me
from programming Pythonically, but for huge classes of problems, it
would.  That's a big deal for me personally -- although I like to have
lots of tools in my toolbox, the one I reach for when doing
exploratory programming is probably going to have exceptions.  And
guess what?  If the exploratory programming winds up being "good
enough" (as often happens), then no recoding is required.

> In theory Go should be akin to C,
> but my gut feeling is that in practice programming in it should not
> feel too much different from
> programming in Python (but I do not have first hand experience).

For well-specified problems, I might be able to agree with you, but
I'm not sure.  Even then, sometimes I build stuff incrementally,
trying out various kinds of internal interfaces.  During that
development process, exceptions are a valuable mechanism for ensuring
that both sides of an interface agree on the contract.  (Obviously,
unit testing is useful in this as well, but premature unit testing can
add friction that makes it difficult to converge on an optimal design
-- it's no fun to be continually rearchitecting unit tests because of
other design decisions.)

What will be interesting to see is if a culture develops inside google
where people prototype in Python or some other language and then
implement the final cut in go.  If this happens often enough and the
cost of recoding the final implementation is deemed high enough, then
the natural question will be "What can we add to go to make it a
better prototyping language?"

Regards,
Pat