Python & Go
kj
I'm just learning about Google's latest: the GO (Go?) language.
(e.g. http://golang.org or http://www.youtube.com/watch?v=rKnDgT73v8s).
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.
> 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
> On Nov 11, 6:53 pm, kj <no.em...@please.post> wrote:
>> I'm just learning about Google's latest: the GO (Go?) language.
>> (e.g.http://golang.orgorhttp://www.youtube.com/watch?v=rKnDgT73v8s).
>> 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.
Actually, numerous analogies have been drawn between the two
both by whoever wrote the docs and the tech media, including
slashdot and techcrunch.
>> the absence of parentheses at the top of
>> flow control constructs,
>
> Huh?
The OP is referring to the fact that for and if do not have
mandatory parenthesis.
>> 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.
The rule is that if its between parens, it needs semicolons.
<snip>
>> 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.
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
> On Wed, Nov 11, 2009 at 9:00 PM, Mensanator <mensana...@aol.com> wrote:
> > On Nov 11, 6:53 pm, kj <no.em...@please.post> wrote:
> >> I'm just learning about Google's latest: the GO (Go?) language.
> >> (e.g.http://golang.orgorhttp://www.youtube.com/watch?v=rKnDgT73v8s).
> >> 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.
>
> 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 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.
Well, it's hard to argue with not being like C++, but the lack of
inheritance is a doozie.
Carl Banks
Mensanator
> On Wed, Nov 11, 2009 at 9:00 PM, Mensanator <mensana...@aol.com> wrote:
> > On Nov 11, 6:53 pm, kj <no.em...@please.post> wrote:
> >> I'm just learning about Google's latest: the GO (Go?) language.
> >> (e.g.http://golang.orgorhttp://www.youtube.com/watch?v=rKnDgT73v8s).
> >> 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.
>
> Actually, numerous analogies have been drawn between the two
> both by whoever wrote the docs and the tech media, including
> slashdot and techcrunch.
>
> >> the absence of parentheses at the top of
> >> flow control constructs,
>
> > Huh?
>
> The OP is referring to the fact that for and if do not have
> mandatory parenthesis.
>
> >> 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.
>
> 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
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
>> Go doesn't support inheritance, so C++ is pretty much out. C
>> is a lot closer, but still not all that close.
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
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
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
http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php
Carl Banks
> On Nov 11, 7:56 pm, geremy condra <debat...@gmail.com> wrote:
>
> > On Wed, Nov 11, 2009 at 9:00 PM, Mensanator <mensana...@aol.com> wrote:
> > > On Nov 11, 6:53 pm, kj <no.em...@please.post> wrote:
> > >> I'm just learning about Google's latest: the GO (Go?) language.
> > >> (e.g.http://golang.orgorhttp://www.youtube.com/watch?v=rKnDgT73v8s).
> > >> 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.
>
> > 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).
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
Duncan Booth
> 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
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 http://www.youtube.com/watch?v=rKnDgT73v8s).
> 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
> kj wrote:
>>
>> I'm just learning about Google's latest: the GO (Go?) language.
>> (e.g. http://golang.org or http://www.youtube.com/watch?v=rKnDgT73v8s).
>> 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,
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.
--
Grant Edwards grante Yow! I have a VISION! It's
at a RANCID double-FISHWICH on
visi.com an ENRICHED BUN!!
Paul Rubin
> > 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:
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.
Duncan Booth
> 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.
I said exceptions or any other method of error handling.
>> 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.
I just read the reference manual. As I understand it:
Any function or method can be executed in parallel: instead of calling
the function you use the go keyword:
go doSomething();
go routines are executed using a thread pool, and an individual go
routine might vary its execution thread depending on which threads are
available.
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.
You can declare and pass around channel variables. A channel can hold
values or pointers of any type and has a specific number of free slots.
e.g.
var ch = make(chan int, 3);
would create a channel that holds 3 int values.
To write to a channel (blocking if it is full):
ch <- value;
To read from a channel (blocking if empty):
value <- ch;
To read from a channel blocking and discarding the result (e.g. to wait
for a routine to finish):
<- ch;
To read without blocking:
value, ok <- ch;
ok set true if something was read. And to write without blocking:
ok := ch <- value;
or in fact any write in an expression context.
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, otherwise if
there is a default statement it executes that. If there is no default
statement the entire select blocks until one of the case statements can
proceed. e.g. (example from the docs)
var c1, c2 chan int;
var i1, i2 int;
select {
case i1 = <-c1:
print("received ", i1, " from c1\n");
case c2 <- i2:
print("sent ", i2, " to c2\n");
default:
print("no communication\n");
}
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.
Paul Rubin
> > Haskell handles lookups through its type system; dealing with
> > lookup errors (say by chaining the Maybe type) is clean and elegant.
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
sturlamolden
> I'm just learning about Google's latest: the GO (Go?) language.
> 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...
It seems that the argument for using Go over Python is speed. They
achieve that by static typing. According to Debian benchmarks, LuaJIT
delivers the same performance as Google cleaims for Go (about 20% loss
compared to C), and that is from a completely dynamic language. (Lua
is Python's sibling.) It makes me wonder what Python would be like on
LuaJIT.
Perhaps we should make a Python frontend for the Lua VM and try? It
would be fun :-)
Anyway, the impressive performance of LuaJIT on Debian benchmarks just
tells med that static typing a la Go is not needed for fast execution
of CPU-bound code.
And looking at Go, I cannot understand why Google prefer this over
e.g. Lua.
Michele Simionato
>
> 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.
Not at all. A language with a small learning curve should be as far as
possible for C++!
Go is in many ways simpler than C (no header files, a simpler
compilation process, no pointer arithmetic, no ternary operator, no
while loop, in a sense no threads, etc) and it has an object
orientation simpler than most languages; actually it looks even
simpler than Python in many respects (no properties, no decorators, no
metaclasses,
a much simpler version of inheritance ...). It has static typing that
makes things a bit more complicated, but also safer in same respect.
It has also reflection and the ability to do a lot of things at
runtime. If people starts writing libraries it has the potential to
cover both C and Python niches at the same time!
John Nagle
> On 12 Nov, 01:53, kj <no.em...@please.post> wrote:
>> I'm just learning about Google's latest: the GO (Go?) language.
It's interesting. The semantics are closer to Java than any other
mainstream language. While Java usually is run with a "virtual machine",
Go is more like Java hard-compiled (which you can do with GCC.)
It's far less dynamic than Python, which is good for performance.
(That's not an inherent problem with Python. It's a problem with the
CPython implementation. See Shed Skin.)
The declaration syntax is borrowed from the Pascal/Modula/Ada
family of languages, and it's an improvement over the C/C++ approach.
I suspect that Go is LALR(1), which means it can be parsed with a
simple context-independent parser. C and C++ are very difficult to
parse, and modules can't be parsed independently. (Because of the
C/C++ type syntax, you have to look up type names to find out how
to parse declarations. So the include files have to be present
to parse declarations. This is why there aren't many tools that
manipulate C and C++ source code.)
Having concurrency in the language is a win. Syntax for queues
is a minor win. But the language doesn't directly address the issue of "who
locks what". There are shared variables, and mutexes, but the language doesn't
let you talk about which variables are shared. When the language doesn't
know that, you either have to restrict optimization (as in Python) or have
painful mechanisms like "mutable" as in C++.
Leaving out exceptions was a mistake. Exceptions are well understood now,
and they're far better than the usual "ignore errors" approach one sees in lamer
C programs.
The interface mechanism is simple enough. In a static language, you can
convert "duck typing" to inheritance at link time, when you have the chance
to see what can match what. So the implementation doesn't actually have to
search for a match at run time.
John Nagle
Paul Rubin
> And looking at Go, I cannot understand why Google prefer this over
> e.g. Lua.
I thought Lua had no type system and no concurrency.
Paul Rubin
> 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.
Mark Chu-Carroll has a new post about Go:
http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
Someone named Mightybyte also has a post about Go, and its comment
thread is similarly pretty good:
http://softwaresimply.blogspot.com/2009/11/standardizing-go.html
One of the commenters wrote something that I felt was similar to my
own impression of the language:
From a PLT perspective Go isn't that interesting. The concurrency and
"goroutines" look promising for possibly being able to do what Erlang
does. The type system is pretty weak. From a practical perspective
people are singing praise for how fast it compiles, but not much
mention so far of how fast the resulting code is. Compare tinycc vs
gcc for speed of compilation vs resulting code performace to see why
I'm skeptical.
sturlamolden
> Syntax for queues is a minor win.
No, that's syntax bloat.
The go keyword could be a problem as well. I suspect it could infringe
on Cilk++ patents. Perhaps Go cannot be used without a licence from
Cilk Arts?
Paul Rubin
> The go keyword could be a problem as well. I suspect it could infringe
> on Cilk++ patents. Perhaps Go cannot be used without a licence from
> Cilk Arts?
Also as somebody said, if after a while they decide to make a new
version of the language, they'll have to call it Go2, which will
necessarily be considered harmful.
Terry Reedy
> Mark Chu-Carroll has a new post about Go:
>
> http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
In a couple of minutes, I wrote his toy prime filter example in Python,
mostly from the text rather than the code, which I can barely stand to
read. It ran the first time without error.
def plurals():
i = 2
while True:
yield i
i += 1
def primefilter(src, prime):
for i in src:
if i % prime:
yield i
src = plurals()
while True:
i = next(src)
print(i)
src = primefilter(src, i)
As I commented there
"It stopped at 7877 when it hit the default recursion limit of 1000,
which could easily be increased to get out-of-memory error instead.
I think Google is making a blunder if it moves to another old-fashioned
language whose code is bloated with junky boilerplate that doubles the
size. It would be much better, for instance, to tweak Python, which it
has had great success with, to better run on multiple cores."
Terry Jan Reedy
Terry Reedy
>
> On Sun, Nov 15, 2009 at 12:10 AM, Terry Reedy <tjr...@udel.edu
> <mailto:tjr...@udel.edu>> wrote:
>
> Paul Rubin wrote:
>
> Mark Chu-Carroll has a new post about Go:
>
> http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
>
>
> Python, mostly from the text rather than the code, which I can
> barely stand to read. It ran the first time without error.
>
>
> generator in a different thread, so in theory it could run twice as fast
> on a multi-core machine.
Which is why I added, in my opinion, that "It would be much better, for
instance, to tweak Python, which it has had great success with, to
better run on multiple cores."
For instance, add a new keyword 'go' such that
go def f(): yield 1
runs the generator in a different thread, possibly on a different core.
To go further, restrict Python's dynamism, require 3.x annotations, and
call the result GoPython ;-).
Actually, it is already possible to post-process code objects to, in
effect, remove the effect of many dynamic assumptions
http://code.activestate.com/recipes/277940/
Perhaps, with a different implementation, not even a keyword is needed,
just a built-in decorator:
@go
def f(): yield 1
The go decorator would replace f with a wrapper that runs instances gf
of f in threads or whatever, calls next(gf) immediately for parallel
opereation, and caches the first yielded value until the calling
function calls next(wrapper) to retrieve it.
It seems to me that generators are already 'channels' that connect the
calling code to the __next__ method, a semi-coroutine based on the body
of the generator function. At present, the next method waits until an
object is requested. Then it goes into action, yields an object, and
rests again. For parallel operations, we need eager, anticipatory
evaluation that produces things that *will* be needed rather than lazy
evaluation of things that *are* needed and whose absence is holding up
everything else.
I see no reason why we cannot have that with Python. I not even sure we
cannot have it with CPython, but I am not familiar enough with threads,
processes, and CPython internals.
Terry Jan Reedy
Steven D'Aprano
> In <7xpr7li...@ruckus.brouhaha.com> Paul Rubin
> <http://phr...@NOSPAM.invalid> writes:
>
>>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).
Python (like many other languages) already has unobtrusive compilation.
That's why you get .pyc files, and that's what the compile() built-in
function does. It is compilation to byte-code rather than machine-code,
but still.
Psyco does JIT compilation to machine-code for CPython, at the cost of
much extra memory. It's also limited to 32-bit Intel processors. The aim
of the PyPy project is to (eventually) make JIT machine-code compilation
available to any Python, on any machine.
--
Steven
Michele Simionato
> Leaving out exceptions was a mistake. Exceptions are well understood now,
> and they're far better than the usual "ignore errors" approach one sees in lamer
> C programs.
I am also surprised about the lack of exceptions. I could infer that
Rob Pike and Ken Thompson are idiots that lack experience with
languages with exceptions, or I could infer that they have reasons for
doing so. I do not know about exceptions enough to have an opinion
myself. However I will notice that in Python, when using threads,
exceptions do not work so well: if I forget to trap an exception in a
thread I see a traceback on stderr, but the other threads continue to
run, basically ignoring the exception. Probably the language that get
things right is Erlang, which is supervising all crashed process and
it is designed to safely recover for unexpected events.
Michele Simionato
> It seems to me that generators are already 'channels' that connect the
> calling code to the __next__ method, a semi-coroutine based on the body
> of the generator function. At present, the next method waits until an
> object is requested. Then it goes into action, yields an object, and
> rests again.
>
> cannot have it with CPython, but I am not familiar enough with threads,
> processes, and CPython internals.
Of course we can have Go capabilities with Python. We already have
generators and the multiprocessing module. It is just a matter of
performance: I assume the Go implementation is more efficient. It
would be nice to have numbers to quantify this claim. One can still
write prototypes in Python and convert them in Go and the process
looks less cumbersome than converting them in C or C++. I could never
force myself to write C or C++; but I do not have any particular
resistence to coding in Go, should I need a performance-oriented
language.
Michele Simionato
"""
Why does Go not have exceptions?
Exceptions are a similar story. A number of designs for exceptions
have been proposed but each adds significant complexity to the
language and run-time. By their very nature, exceptions span functions
and perhaps even goroutines; they have wide-ranging implications.
There is also concern about the effect they would have on the
libraries. They are, by definition, exceptional yet experience with
other languages that support them show they have profound effect on
library and interface specification. It would be nice to find a design
that allows them to be truly exceptional without encouraging common
errors to turn into special control flow that requires every
programmer to compensate.
Like generics, exceptions remain an open issue.
"""
Steve Howell
> 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.
>
By "set in stone," do you mean "implemented"? Or have Rob Pike and
friends literally put a redesign freeze on the language that was just
released this month?
sturlamolden
cybersource.com.au> wrote:
> Psyco does JIT compilation to machine-code for CPython, at the cost of
> much extra memory. It's also limited to 32-bit Intel processors. The aim
> of the PyPy project is to (eventually) make JIT machine-code compilation
> available to any Python, on any machine.
Who wants a JIT when it's orders of magnitude slower than interpreted
Python?
Simon Forman
>>
>>
>> http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
>
> mostly from the text rather than the code, which I can barely stand to read.
> It ran the first time without error.
>
> i = 2
> while True:
> yield i
> i += 1
>
> def primefilter(src, prime):
> for i in src:
> if i % prime:
> yield i
>
> src = plurals()
> while True:
> i = next(src)
> print(i)
> src = primefilter(src, i)
>
> As I commented there
> "It stopped at 7877 when it hit the default recursion limit of 1000, which
> could easily be increased to get out-of-memory error instead.
>
> I think Google is making a blunder if it moves to another old-fashioned
> language whose code is bloated with junky boilerplate that doubles the size.
> great success with, to better run on multiple cores."
>
FWIW,
def plurals():
i = 3
while True:
yield i
i += 2
sturlamolden
> It would be much better, for instance, to tweak Python, which it
> has had great success with, to better run on multiple cores."
Python run well on multiple cores, you just have to use processes
instead of threads.
Terry Reedy
> On Sat, Nov 14, 2009 at 5:10 PM, Terry Reedy <tjr...@udel.edu> wrote:
>> Paul Rubin wrote:
>>
>>>
>>>
>>> http://scienceblogs.com/goodmath/2009/11/the_go_i_forgot_concurrency_an.php
>> mostly from the text rather than the code, which I can barely stand to read.
>> It ran the first time without error.
>>
>> def plurals():
>> i = 2
>> while True:
>> yield i
>> i += 1
>>
>> def primefilter(src, prime):
>> for i in src:
>> if i % prime:
>> yield i
>>
>> src = plurals()
>> while True:
>> i = next(src)
>> print(i)
>> src = primefilter(src, i)
>>
>> As I commented there
>> "It stopped at 7877 when it hit the default recursion limit of 1000, which
>> could easily be increased to get out-of-memory error instead.
>>
>> I think Google is making a blunder if it moves to another old-fashioned
>> language whose code is bloated with junky boilerplate that doubles the size.
>> great success with, to better run on multiple cores."
>>
>
> FWIW,
>
> def plurals():
> i = 3
> while True:
> yield i
> i += 2
Of course, in fact, I thought of at the time
def plurals():
i = 6
while True:
yield i-1
yield i+1
i += 6
5,7, 11,13, 17,19, 23,(25-first miss), 29,31, (35-2nd miss),37, 41,43,
47,(49 erd)...Reduced the base cases by another 1/3. I *think* without
measuring, that that compensates for the extra -1,+1. But I was
implementing *Mark's* toy example, and first posted it on his blog, so I
copied his naive version.
Even better, to avoid extra -1, +1
def plurals():
yield 2
yield 3
i = 5
while True:
yield i
i += 2
yield i
i += 4
Of course, testing with primes greater that square root(candidate) is
wasteful, and recusion should be converted to iteration to avoid
recursion limit.
Terry Jan Reedy
Terry Reedy
But not so trivially as to add one word to an existing function.
Hence by tweak, I meant, as explained in another post, to add a keyword
or just a decorator that will do what the go keyword does in go.
sturlamolden
> > Python run well on multiple cores, you just have to use processes
> > instead of threads.
>
> But not so trivially as to add one word to an existing function.
> Hence by tweak, I meant, as explained in another post, to add a keyword
> or just a decorator that will do what the go keyword does in go.
A decorator function like @go could just call os.fork and run the
function in the child. We already have a between-process Queue in
multiprocessing to use as channels.
Or we could have a context manager that forks in __enter__ and
waitpids or exits in __exit__. The body of the with-statement would
then be executed in the child process, the parent would just raise an
exception to skip directly to __exit__.
Not rocket science as all. Yes that would give us a new isolated
process, but such isolation is present in Erlang as well.
(Windows is more tricky though, as there is no efficent fork.)
Graham Breed
> It seems to me that generators are already 'channels' that connect the
> calling code to the __next__ method, a semi-coroutine based on the body
> of the generator function. At present, the next method waits until an
> object is requested. Then it goes into action, yields an object, and
> rests again. For parallel operations, we need eager, anticipatory
> evaluation that produces things that *will* be needed rather than lazy
> evaluation of things that *are* needed and whose absence is holding up
> everything else.
Yes, generators look very much like channels. The obvious
thing, from where I'm sitting, is to have a function called
"channel" that takes an iterator, runs it in a different
thread/process/goroutine, and returns an iterator that reads
from the channel. A single threaded version would look very
much like "iter" so let's use iter to get a working example:
#!/usr/bin/python2 -u
channel = iter # placeholder for missing feature
def generate():
i = 2
while True:
yield i
i += 1
def filter(input, prime):
for i in input:
if i%prime != 0:
yield i
ch = channel(generate())
try:
while True:
prime = ch.next()
print prime
ch = channel(filter(ch, prime))
except IOError:
pass
That works fine in a single thread. It's close to the
original go example, hence the evil shadowing of a builtin.
I don't think the "channel" function would present any
problems given an appropriate library to wrap. I got
something like this working with Jython and the E language
but, as I recall, had an accident and lost the code. If
somebody wants to implement it using multiprocessing, go to it!
Graham
Paul Rubin
> A decorator function like @go could just call os.fork and run the
> function in the child. We already have a between-process Queue in
> multiprocessing to use as channels.
Unlike with interthread queues, you have to serialize the values sent
through those multiprocessing channels. I don't think you can send
functions, generators, file descriptors, etc.
Donn
> they'll have to call it Go2
Or we could fork it and call it Gosub ... and never return!
\d