11–20 of 37 posts
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.
C. A. R. Hoare, ``Communicating Sequential Processes,'' Communications of the ACM 21(8) (August 1978), 666-677.
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 opera…
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 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.
1960s? C. A. R. Hoare, ``Communicating Sequential Processes,'' Communications of the ACM 21(8) (August 1978), 666-677.
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 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 stil…
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?
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.
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.
rob's talk: http://www.youtube.com/watch?v=rKnDgT73v8s
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...
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.
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.
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-threade…
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 opera…
"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…