

Why I'm not very excited about Go - kingkilr
http://lazypython.blogspot.com/2009/11/why-im-not-very-excited-about-go.html

======
scott_s
_Constructs like concurrency should not be granted their own syntax,
especially when they can be cleanly implemented using the other constructs of
a language, look at the C library libtask as an example._

See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as
a Library": <http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf>

The abstract explains the argument:

 _In many environments, multi-threaded code is written in a language that was
originally designed without thread support (e.g. C), to which a library of
threading primitives was subsequently added. There appears to be a general
understanding that this is not the right approach. We provide specific
arguments that a pure library approach, in which the compiler is designed
independently of threading issues, cannot guarantee correctness of the
resulting code.We first review why the approach almost works, and then examine
some of the surprising behavior it may entail. We further illustrate that
there are very simple cases in which a pure library-based approach seems
incapable of expressing an efficient parallel algorithm.Our discussion takes
place in the context of C with Pthreads, since it is commonly used, reasonably
well specified, and does not attempt to ensure type-safety, which would entail
even stronger constraints. The issues we raise are not specific to that
context._

As far as I can tell, goroutines are similar to the block mechanisms and
runtime system in Grand Central Dispatch, which is the same concept of
concurrency in Cilk (<http://supertech.csail.mit.edu/cilk/> and the paper "The
Implementation of the Cilk-5 Multithreaded Language" in particular:
<http://supertech.csail.mit.edu/papers/cilk5.pdf>).

~~~
cabalamat
I'm not a big fan of Java, but one of its good points is that threads are part
of the language and their behaviour is predicatable across implementations.

~~~
wavesplash
That isn't really the case. Java's threading can either be green threads or OS
threads and there's no way as a programmer to know what the JVM implements on
any given platform.

~~~
cabalamat
I stand corrected. Thanks.

------
stcredzero
_The first major mistake was using a C derived syntax_

Personally, I'm not that interested in the particulars of indentation/block
delimiting. I'm much more interested in _what_ one can do with blocks. This
has much more bearing on the power of a programming language. If this is the
1st issue discussed, it's a poor portent for the rest of the article.

 _The next mistake is having a separate declaration and assignment operator._

Is this really so different from having a separate comparison and assignment
operator? Or having 2 or 3 flavors of comparison?

 _The final mistake was not providing generics._

This is a work in progress.

 _C++'s templates is one of the things that make the language head and
shoulders more useful for me than C...One of the things I've found makes me
most productive in Python is that any time I need to perform a task I simply
pick the data structure that does what I want_

I think you can have completely generic collections in Go if you give up type
safety for it.

 _In terms of features which I believe are overhyped the most important one is
the "goroutine"._

It's my understanding that one can use "goroutines" to implement your own
rather powerful control structures. I'm not sure one really needs exceptions
if you have goroutines, channels, and multiple return values. On the other
hand, there are very compelling reasons for not having exceptions, given
goroutines and channels.

 _Further, the handling of interfaces, though interesting, appears to be an
implementation of C++0x's proposed concepts...I view this feature as something
that is most useful in the context of generics_

Thsi makes it seem as if you view programming somewhat through the lens of
generics. This treatment of Interfaces gives you one of the best things about
"Duck Typing" languages, but in a statically typed language: "emergent"
interfaces.

~~~
sedachv
"It's my understanding that one can use "goroutines" to implement your own
rather powerful control structures. I'm not sure one really needs exceptions
if you have goroutines, channels, and multiple return values. On the other
hand, there are very compelling reasons for not having exceptions, given
goroutines and channels."

The "goroutines" are just threads. They're not useful for building control
structures. Unless you have continuations/a reified control stack or program
in a monadic style (which would essentially be CPS in this case), you cannot
"fake" exceptions.

~~~
stcredzero
I'm not talking about "faking" exceptions. I'm talking about just not using
them. Instead of "catching" exceptions down (up? In my debugger, it's down)
the stack, you can just detect errors and send something down a channel. If
you can conveniently send the current function's pointer, or better yet, the
current context, you can do much of what you'd use exceptions for.

~~~
sedachv
How do you detect errors? That's the question that the exception-handling part
of exceptions is designed to solve. Having every function need a reference to
a channel is really no different than error detection using return codes.

------
shib71
He seems to be criticizing Go for not being Python. My understanding is that
Go is designed with an obsessive need for speed and concurrency in mind. It's
a little silly to compare it to Python without accounting for that.

~~~
dkersten
_designed with ... speed and concurrency in mind_

I won't argue with the speed part, but I feel the concurrency support is a bit
weak. Go routines, locks and channels don't seem enough to me for a language
that was designed _with concurrency in mind_.

Hell, if thats all it takes, I would argue that Python 2.6, with its
multiprocessing module, is designed for concurrency. Now, I do think that
these features are an improvement over C and C++, but they seem to fall a bit
short of more modern languages.

~~~
thenduks
You should really try it. Erlang (or Scala with Actors) might be a better
place to start to get a feel, but that's just me.

~~~
dkersten
I should try what? Go?

Regarding concurrency, I've been playing a lot with Clojure recently, whose
agents are similar to actors.

~~~
thenduks
Yea sorry, I meant 'it' as in Go/Erlang/Scala-Actors style concurrency. If
Clojure has something similar then that's cool too. I'm just saying it's
pretty game-changing compared to stuff like libraries for Python (imo, of
course).

------
rbanffy
Sometimes, criticizing a programming language sounds like saying Japanese
sucks because it's not German.

I feel (never have written a line of code with it) Go is not particularly
expressive - when you read someone else's code it's not obvious what is being
done. What you see is how cleverly it's being done. The language has to hit
the sweet spot between these two extremes - making the how obvious by hiding
the what and showing the what by hiding the how. Python is in this sweet spot.
Go doesn't seem so.

Perhaps this is a problem with Go programmers that will be ironed out
eventually.

And as for concurrency having its own syntax, I am not sure. I would love (in
Python) to have a concurrent list comprehension that spreads the work between
as many processors as there are available. OTOH, it could be implemented as a
method of generator expressions with semantics like "with this generator, do
10 values in advance".

Hmmm...

Too bad we are in a feature moratorium...

------
gfodor
When I read arguments that include syntax complaints, I really have a hard
time taking anything else the author says seriously. It's like a car buyer
critiquing in detail crash safety ratings, gas mileage, steering control, and
then for no particular reason going on a rant about the optimal arrangement of
cup-holders.

~~~
kingkilr
If I spent 50%+ of my day reading cup-holders I'd agree with you. I _may_ have
over extended that metaphor.

~~~
gfodor
Right, well, I'm referring to the majority of syntax complaints which fall
into "I hate braces!" or "Why do the brackets come first and not second?!"
Really folks, it doesn't matter. Now, if you had syntax that will result in a
massive decrease in efficiency I'm willing to listen. For example, the
"function" keyword in Javascript or the lack of implicit typing during
assignment in Java are worth talking about, but really at the end of the day
they are the least of your problems when considering the limitations of a
language.

------
sedachv
I honestly don't get what the point of Go is. Why not D? Why not Modula3?
There is nothing at all compelling in the feature set. Just look at the crap
they put in for the built-in concurrency primitives:

<http://golang.org/doc/go_mem.html>

So we're back to CSP. Welcome to the 1960s.

~~~
thenduks
I'm not sure how 'crap' comes to mind just _looking_ at the concurrency
primitives. You seem to have something against `<`s and `-`s?

The 'point' of Go is to be a 'expressive, concurrent, garbage-collected'
systems language. It's very early in it's lifecycle and of course immature at
the moment... Let's just wait and see what happens in stead of writing it off,
shall we?

~~~
sedachv
Umm, yeah, I've been researching and programming concurrent systems for some
time now. CSP is not a good way of doing that.

Go is not very early in its lifecycle. Just look at the feature set - it's the
very direct continuation of the work Pike and Thompson were doing on Plan9.

~~~
thenduks
_CSP is not a good way of doing that._

Someone should tell Ericsson!

 _...plan9..._

Well... I don't know, I'd consider a language started around the mid nineties
pretty early in it's life-cycle. But it's pretty clear to me that which it may
be a 'continuation' it's definitely not just 'rebranded'. This is a new
project and there's tons of talk all over the place about how "we're working
on that". The garbage collector isn't even done yet!

~~~
sedachv
Erlang is based on message passing ala Actors. Very different things.

Take a look at this if you don't believe that their approach hasn't changed:
<http://swtch.com/~rsc/thread/>

