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.
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).
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.
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.
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.
"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."
I continually find exception handling to be a huge source of frustration; especially Java's checked exceptions. If I explicitly test for something in my method before calling another method, should I still have to catch, rethrow or declare that I throw its exception? If I don't check for the exceptional case first, then aren't I now using exceptions for flow control?
Unchecked exceptions seem a little more logical to me, but they still seem to cause disagreement on how they should be used.
The fact that they decided to put exception handling on hold here for now is really encouraging to me.
"there are very compelling reasons for not having exceptions, given goroutines and channels"
This confuses me I would have thought the opposite would be true. The goroutine/channel concept seems Erlang like to me. Erlang uses exceptions, if a process crashes an exception is thrown to its parent which can then act appropriately. How does Go handle this, i.e. if a goroutine crashes who gets informed and how?
goroutines are Erlang-like. Erlang doesn't have 'exceptions' though. In Erlang, if a process crashes (simulated or unexpectedly) it implicitly sends a specific message to it's parent. In Go you can emulate this by just checking for return values of stuff you do in the goroutine and send a similar message if it fails.
The fact that Go is in early development here and I'd say this both could and will be improved in the future.
"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.
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.
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.
You can build one-shot continuations on top of asymmetrical co-routines, though, and multi-shot continuations if you can copy them. I don't know about "goroutines", but I've done it with the co-routines in Lua.
A mostly agree with your point of view. I would like to add that I think the author confuses generics with templates. The former is done using casting and RTTI, while the later is done by generating new code / new classes.
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.
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.
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).
programming languages influence how you think about programming to such a degree that it's difficult to reason objectively about them.
it's rare for me to watch long videos, because they are information-poor for the time investment, but i watched rob pike talk for an hour about go this evening. a lot of it is really interesting, but a lot of things about the syntax made me think: ow, that's going to be painful for me if it becomes successful.
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".
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.
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.
It does matter to people. They have to read it and type it all day, and as decades of language wars make clear, people care what their code looks like.
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:
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?
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.
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!
You're going to be down-voted to oblivion as my comment was here: http://news.ycombinator.com/item?id=938814. Google of 2009 has become the Microsoft of 1999. They can release anything and people will love them for it without skepticism. Let them. The sheep can follow their new overlord while the rest of us actually innovate. I highly suspect had Yahoo or Microsoft Research released Go, it would have received a much more lacklustre reception.
I thought my being downvoted here had more to do with linking to a negative (towards Go) comment, rather than the comment itself. My other comments critical of Google Go have been generally upvoted. But you're right. I think if Google weren't involved, nobody would even give Go a second look.
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).