Why I'm not very excited about Go
lazypython.blogspot.com
Why I'm not very excited about Go
1–10 of 37 posts
Re: Why I'm not very excited about Go
#2The 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.
Re: Why I'm not very excited about Go
#3He 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.
Re: Why I'm not very excited about Go
#4The 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 opera…
"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.
Re: Why I'm not very excited about Go
#5Constructs 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).
Re: Why I'm not very excited about Go
#6When 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.
Re: Why I'm not very excited about Go
#7When 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.
If I spent 50%+ of my day reading cup-holders I'd agree with you. I may have over extended that metaphor.
Re: Why I'm not very excited about Go
#8He 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.
Yeah, the braces make it execute faster.
Re: Why I'm not very excited about Go
#9I 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.
Re: Why I'm not very excited about Go
#10The 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 opera…
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.