Another "Go is Python-like" article.

G

Grant Edwards

In a recent Reg article, there's yet more yammering on about how Go is
somehow akin to Python -- referring to Go as a "Python-C++" crossbreed.

http://www.theregister.co.uk/2010/05/20/go_in_production_at_google/

I still don't get it.

What about Go, exactly, do people see as Phython-like?

Go doesn't seem to have any of the salient features (either syntactic
or semantic) of Python other than garbage collection.

How is Go not just warmed-over Java?
 
D

David Cournapeau

In a recent Reg article, there's yet more yammering on about how Go is
somehow akin to Python -- referring to Go as a "Python-C++" crossbreed.

http://www.theregister.co.uk/2010/05/20/go_in_production_at_google/

I still don't get it.

What about Go, exactly, do people see as Phython-like?

I guess the type system without a strict hierarchy, as well as very
fast compilation enabling fast iteration. Granted, a lot of languages
have those features nowadays, and I doubt anyone would speaks about it
if it was not where it was coming from. The fact that google feels the
need to create a new system programming language is maybe the most
interesting fact of it ?

cheers,

David
 
J

John Roth

In a recent Reg article, there's yet more yammering on about how Go is
somehow akin to Python -- referring to Go as a "Python-C++" crossbreed.

http://www.theregister.co.uk/2010/05/20/go_in_production_at_google/

I still don't get it.

What about Go, exactly, do people see as Phython-like?

Go doesn't seem to have any of the salient features (either syntactic
or semantic) of Python other than garbage collection.

How is Go not just warmed-over Java?

Actually, Go seems to be more C implemented the way the C developers
would have done it if they knew then what they know now. That's not a
joke - look at the names on the development team.

I haven't a clue how anyone can think it's similar to Python. Or Java,
for that matter.

John Roth
 
M

Michele Simionato

What about Go, exactly, do people see as Python-like?

The philosophy of keeping things simple. I find the concurrency
mechanism quite Pythonic.
Moreover Go interfaces are quite akin to Python duck typing, but
better. There also things which are quite different from Python e.g.
the attitude towards exceptions. 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).

Michele Simionato
 
P

Patrick Maupin

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
 
S

Steven D'Aprano

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.

That's two possible explanations. A third is that they genuinely believe
that exceptions lead to poor programming practice and left them out, just
as the designers of many other languages believe that goto leads to poor
practice and leave it out as well.

I don't think there's necessarily anything "childish" about choosing to
leave out a language feature that you think is bad from a language you
design.


Indeed, when I design my killer language, the identifiers
"foo" and "bar" will be reserved words, never used, and not
even mentioned in the reference manual. Any program using
one will simply dump core without comment. Multitudes will
rejoice. -- Tim Peters, 29 Apr 1998
 
P

Patrick Maupin

That's two possible explanations. A third is that they genuinely believe
that exceptions lead to poor programming practice and left them out, just
as the designers of many other languages believe that goto leads to poor
practice and leave it out as well.

I don't think there's necessarily anything "childish" about choosing to
leave out a language feature that you think is bad from a language you
design.

While I admit that "childish" is an inflammatory simplification, other
than that, I think that your possible explanation is, essentially,
identical to my first possibility -- why would you think exceptions
were bad if you didn't have first-hand evidence of that?

Regards,
Pat
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top