Python & Go

[kj]

I'm just learning about Google's latest: the GO (Go?) language.
(e.g. http://golang.org or

).
There are some distinctly Pythonoid features to the syntax, such
as "import this_or_that", the absence of parentheses at the top of
flow control constructs, and quite a few statements without a
trailing semicolon. Then again, there's a lot that looks distinctly
un-Pythonlike, such as the curly brackets all over the place. And
among the un-Pythonlike stuff there's a lot that looks like nothing
else that I've ever seen...

Just out of curiosity, how much did GvR contribute to this effort?

Cheers,

G.

P.S. Keeping up with Google is becoming a full-time job. It's
friggin non-stop. Who can handle it? Truly incredible.

 

[Mensanator]

I'm just learning about Google's latest: the GO (Go?) language.
(e.g.

).
There are some distinctly Pythonoid features to the syntax, such
as "import this_or_that",

There's more to Python than import statements.
In fact, this Go language is nothing like Python.

the absence of parentheses at the top of
flow control constructs,
Huh?

and quite a few statements without a
trailing semicolon.  

Those are exceptions, the rule appears to be "ends with semicolon".
In this example, I see semicolons all over the place.

05 package main

07 import (
08 "./file";
09 "fmt";
10 "os";
11 )

13 func main() {
14 hello := []byte{'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o',
'r', 'l', 'd', '\n'};
15 file.Stdout.Write(hello);
16 file, err := file.Open("/does/not/exist", 0, 0);
17 if file == nil {
18 fmt.Printf("can't open file; err=%s\n", err.String());
19 os.Exit(1);
20 }
21 }

Then again, there's a lot that looks distinctly
un-Pythonlike, such as the curly brackets all over the place.  
Duh.

And
among the un-Pythonlike stuff there's a lot that looks like nothing
else that I've ever seen...

Go look at a C++ program sometime.

Just out of curiosity, how much did GvR contribute to this effort?

I hope none that he would admit to.

 

[geremy condra]

There's more to Python than import statements.
In fact, this Go language is nothing like Python.

Actually, numerous analogies have been drawn between the two
both by whoever wrote the docs and the tech media, including
slashdot and techcrunch.

Huh?

The OP is referring to the fact that for and if do not have
mandatory parenthesis.

Those are exceptions, the rule appears to be "ends with semicolon".
In this example, I see semicolons all over the place.

The rule is that if its between parens, it needs semicolons.

Go look at a C++ program sometime.

Go doesn't support inheritance, so C++ is pretty much out. C
is a lot closer, but still not all that close.

Geremy Condra

 

[Carl Banks]

Actually, numerous analogies have been drawn between the two
both by whoever wrote the docs and the tech media, including
slashdot and techcrunch.

Superficially it looks quite hideous, at least this sample does, but
underneath the covers might be another question. Javascript looks
like Java but behaves more like Python. Such might also be the case
for Go. I'll reserve judgment till I've looked at it, but it's
advertised as natively supporting something I've always wanted in a
static language: signatures (and, presumably, a culture to support
them).


[snip]

Go doesn't support inheritance, so C++ is pretty much out. C
is a lot closer, but still not all that close.

Well, it's hard to argue with not being like C++, but the lack of
inheritance is a doozie.


Carl Banks

 

[Mensanator]

Actually, numerous analogies have been drawn between the two
both by whoever wrote the docs and the tech media, including
slashdot and techcrunch.



The OP is referring to the fact that for and if do not have
mandatory parenthesis.



The rule is that if its between parens, it needs semicolons.

<snip>

Why did you snip the example that proves you're wrong?

 

[geremy condra]

Why did you snip the example that proves you're wrong?

For the very simple reason that I'm not. From the roughly
20 minute tutorial:

"Semicolons aren't needed here; in fact, semicolons are unnecessary
after any top-level declaration, although they are needed as
separators within a parenthesized list of declarations."

In fact, you can clearly see this in action even in the example
you posted- there is no semicolon after the import, nor is one
required after any initialization or where line endings are
unambiguous, such as immediately preceding the end of a
block.


Geremy Condra

 

[Vincent Manis]

OK, if that's the case (I haven't read the Go documents), then Go is nothing like Python, no matter how many or few semicolons there are in Go programs, or whether one imports external code modules with `import', `require', or `iwant'.

Programming languages are similar if their *semantics* are similar, not if their *syntaxes* are similar. A device that apparently has brake and accelerator pedals is similar to a car if the functions of these two pedals match those of a car, and is different from a car if the `brake' causes bread to be inserted into a toaster and the `accelerator' drops a 16ton weight on the driver.

-- v

 

[Mensanator]

For the very simple reason that I'm not. From the roughly
20 minute tutorial:

"Semicolons aren't needed here; in fact, semicolons are unnecessary
after any top-level declaration, although they are needed as
separators within a parenthesized list of declarations."

In fact, you can clearly see this in action even in the example
you posted- there is no semicolon after the import, nor is one
required after any initialization or where line endings are
unambiguous,

So, where line endings ARE ambiguous requires
semicolons. The above statement may be true for
top-level statements, but not within blocks, as
the example clearly shows. The lines were NOT
within parens, yet had trailing semicolons.

You're still wrong.

 

[Michele Simionato]

Well, Go looks like Python in the philosophy (it is a minimalist, keep
it simple language) more than in the syntax.
The one thing that I really like is the absence of classes and the
presence of interfaces
(I have been advocating something like that for years). I am dubious
about the absence of exceptions, though.
If I can attempt a prediction, I would say that if the language will
be adopted internally in Google it will make a difference; otherwise,
it will be rapidly forgotten.

 

[Michele Simionato]

I forgot to post a link to a nice analysis of Go:
http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php

 

[Carl Banks]

Superficially it looks quite hideous, at least this sample does, but
underneath the covers might be another question.  Javascript looks
like Java but behaves more like Python.  Such might also be the case
for Go.  I'll reserve judgment till I've looked at it, but it's
advertised as natively supporting something I've always wanted in a
static language: signatures (and, presumably, a culture to support
them).

Ok, I've read up on the language and I've seen enough.
I, for one, won't be using it.

I don't think it has any possibility of gaining traction without
serious changes. If Google decides to throw money at it and/or push
it internally (and I am skeptical Google's software engineers would
let themselved be browbeaten into using it) it'll be Lisp 2: Electric
Boogaloo.


Carl Banks

 

[kj]

...but the lack of
inheritance is a doozie.

That's what I like most about it. Inheritance introduces at least
as many headaches as it solves. For one, it leads to spaghetti
code. When reading such code, to follow any method call one must
check in at least two places: the base class and the subclass.
The deeper the inheritance chain, the more places one must check.
For every method call. Yeecch. Good riddance.

kj

 

[Patrick Sabin]

Well, it's hard to argue with not being like C++, but the lack of
inheritance is a doozie.

Well it has the concept of embedding, which seems to be similar to
inheritance.

- Patrick

 

[Patrick Sabin]

I'm just learning about Google's latest: the GO (Go?) language.
(e.g. http://golang.org or

).
There are some distinctly Pythonoid features to the syntax, such
as "import this_or_that", the absence of parentheses at the top of
flow control constructs, and quite a few statements without a
trailing semicolon. Then again, there's a lot that looks distinctly
un-Pythonlike, such as the curly brackets all over the place. And
among the un-Pythonlike stuff there's a lot that looks like nothing
else that I've ever seen...

I don't see many similarities with python, especially it's syntax looks
completely different to me. Google Go introduces many new concepts.
Interfaces work a little bit like duck typing. You may call that
python-style. And it has go-routines, which are a bit similar to
generators (although I haven't look at them in detail). There is no
exception handling, but channels should be able to substitute them,
although I haven't checked that.

At a first look it seems, that using Google Go effectively, someone has
to relinquish many programming habits and adapt lots of new ones.

- Patrick

 

[Grant Edwards]

I don't see many similarities with python,

Same here. Go syntax is much more like C/Java than Python.

Sematically, I don't see much that's similar either. Go is
statically typed. Go has no inheritence. Go has no exceptions
( no practical error handling AFAICT). Despite all the people
who keep saying it's similar to Python, I don't really see what
they're talking about. It seems more like C with garbage
collection and interfaces, or maybe cleaned-up Java.

 

[Paul Rubin]

Thanks for that link. I think it pretty well agrees with my first
impressions of Go:

It looks like a not-so-interesting C follow-on, but the article doesn't
describe any of the parallelism stuff.

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.

Nah, exceptions are an ugly effect that gets in the way of
parallelism. Haskell handles lookups through its type system; dealing
with lookup errors (say by chaining the Maybe type) is clean and
elegant. Erlang handles it by crashing the process, and dealing with
the crash through a supervision tree that cleans up after crashes and
restarts the crashed processes.

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...

I'd like to know more about this; is there a link with a short
write-up? I haven't gotten around to looking at the reference
materials.

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.

I'd also like to have seen a more serious type system, like ML's or
better. But they seemed to really be after a fast, lightweight
compiler.

Anyway, it doesn't like even slightly intended to be in the same space
as Python. It's more like a de-bureaucratized replacement for Java.

 

[Paul Rubin]

I said exceptions or any other method of error handling.

I think the use of an option type (like Maybe) is pretty standard
and works fine. Go's use of multiple-value returns isn't so bad,
but seems old-fashioned.

go routines are executed using a thread pool,...
Most types are not thread safe, so you should never access any mutable
value from more than one go routine. If you need to access something
like a map from multiple parallel routines you need to use channels to
protect it.

OK, this sounds sort of like Erlang.

var ch = make(chan int, 3);
would create a channel that holds 3 int values. ...
You can also use a select statement (syntax similar to a switch
statement) to read or write channels in parallel. It arbitrarily chooses
one of the case statements that can proceed to execute,...

Thanks, that is informative. The mechanism looks kind of primitive
and it would be nice if there were a higher level wrapper of some
sort. But again, it seems sort of Erlang-like (though I haven't used
Erlang so I only have a vague sense of its similarity).

There doesn't seem to be any way to specify a timeout on a read or
write. I think you can create a timer channel with regular ticks and
select from that to provide an effective timeout, but that sounds like a
lot of boilerplate if you have to do very often.

I wonder how Erlang handles this.

It seems a little weird to me that they (Google) are concerned with
the speed of the compiler, indicating that they plan to write enormous
programs in the language. I've heard they use a 1000-node cluster to
compile their large C++ apps. Go seems too primitive (so far) to
really be suitable for such large-scale development, and (for a newly
designed language) seems to be missing a lot of the latest ideas.

 

[Michele Simionato]

It seems a little weird to me that they (Google) are concerned with
the speed of the compiler, indicating that they plan to write enormous
programs in the language.  I've heard they use a 1000-node cluster to
compile their large C++ apps.  Go seems too primitive (so far) to
really be suitable for such large-scale development, and (for a newly
designed language) seems to be missing a lot of the latest ideas.

It does not look so primitive to me, compared to commonly used
languages.
I am pretty sure that they are "missing a lot of the latest ideas" on
purpose. If they want to succeed and make Go a popular language in the
Google
infrastructure (ideally replacing C++) their selling point must be a
nearly zero
learning curve. Python succeded with the low learning curve idea. I
wish them
the best. Certainly it is time to replace C with something more
modern, be it Go
or some other language.

 

[kj]

It seems a little weird to me that they (Google) are concerned with
the speed of the compiler, indicating that they plan to write enormous
programs in the language.

Fast compilation also means that Go can conceivably become an
attractive alternative to interpreted languages, because the
compilation stage can be made as unobtrusive as, say, Python's
byte-compilation stage (except that the Go compiler is generating
native code). I believe that OCaml already offers a way to run
code via such on-the-fly compilation, but I doubt that OCaml's
compilers are as fast as Go's.

kynn

 

[kj]

It does not look so primitive to me, compared to commonly used
languages.
I am pretty sure that they are "missing a lot of the latest ideas" on
purpose. If they want to succeed and make Go a popular language in the
Google
infrastructure (ideally replacing C++) their selling point must be a
nearly zero
learning curve. Python succeded with the low learning curve idea. I
wish them
the best. Certainly it is time to replace C with something more
modern, be it Go
or some other language.

The two goals of replacing C with "something more modern" and at
the same time have a "nearly zero learning curve" seem to me mutually
negating. The closer to zero the learning curve is, the closer to
C/C++, and therefore the less modern, that language will be.

The "dark matter" in this discussion Google's projected OS, Chrome.
Will Go be to Chrome what C was/is to Unix? The close collaboration
between Rob Pike and Ken Thompson in this project gives reason to
think so. And if so, how has the design of Chrome shaped the design
of Go?

One more thing: I found Rob Pike's mutterings on generics (towards
the end of his rollout video) rather offputting, because he gave
the impression that some important aspects of the language were
not even considered before major decisions for it were set in stone.
It looks like, if they ever get around to supporting generics, it
will be a late-in-the-day hack.

kynn