How I Learned to Stop Worrying and Love Golang(corte.si)
corte.si
How I Learned to Stop Worrying and Love Golang
http://corte.si/posts/code/go/golang-practicaly-beats-purity/index.html
3 comments
Yeah, "ok" here really signals whether or not the channel is closed. It will still block unless c is buffered.
There are actually a number of other errors in this post, unfortunately, even though I agree with the general conclusion.
There are actually a number of other errors in this post, unfortunately, even though I agree with the general conclusion.
"<-c", regardless of what's on the left side of it will block in every case until there's a messages available in the channel (note that close is a message).
I just notice this section has been removed. I'll be less angry now. :)
I just notice this section has been removed. I'll be less angry now. :)
Should also note that the "arrays are values" thing doesn't actually matter in practice. I've written a wide variety of go code in the last > 4 years and I can only think of two places I've used an array.
> Instead of creating the atomic elements needed to support generic data structures then adding a suite of them to the standard library, the Go team went the other way. There was a concrete use case for good data structures, and so they were added. Attempting a deep reconciliation with the rest of the language was a secondary requirement that was so unimportant that it fell by the wayside for Go 1.x.
For the last year or so, Go has essentially been my primary language. Before that, my primary languages were Python and Lisp (various dialects).
I don't think that anybody who uses Go extensively will deny that they have some feature $X that they'd love to have added to Go[0]. (For me, I miss being able to use some common Lisp idioms).
However, what I like the most about Go is that they don't "just add it" simply because some people suggest it, the way that other languages might. The feature set is incredibly minimal - while it's impossible to get rid of all redundancy, programming in Go is a very consistent experience, because everything that's been done feels like it's been done the right way[1].
Also, from the original post (the one that this blog post partially retracts):
> the exhilarating sense of weightlessness that you get when hacking in Python is largely due to the fact that the language works really, really hard to optimize this process. Go has given away this feeling of exhilaration, basically for nothing.
Hopefully the author now realizes that what Go gives up (only marginally) in "weightlessness" while developing is made up more than tenfold when maintaining code.
I honestly don't bat an eyelid anymore when I need to refactor Go code, even if I've forgotten to write tests[2]. It doesn't take anywhere near as long as refactoring Python takes me, and I don't worry as much about introducing logical errors (or worse, runtime exceptions).
[0] Incidentally, "generics" doesn't seem to be a common complaint among people who have actually programmed in Go for a moderate length of time, anecdotally.
[1] Yes, this is subjective.
[2] Yes, I know. Always write tests. But still.
For the last year or so, Go has essentially been my primary language. Before that, my primary languages were Python and Lisp (various dialects).
I don't think that anybody who uses Go extensively will deny that they have some feature $X that they'd love to have added to Go[0]. (For me, I miss being able to use some common Lisp idioms).
However, what I like the most about Go is that they don't "just add it" simply because some people suggest it, the way that other languages might. The feature set is incredibly minimal - while it's impossible to get rid of all redundancy, programming in Go is a very consistent experience, because everything that's been done feels like it's been done the right way[1].
Also, from the original post (the one that this blog post partially retracts):
> the exhilarating sense of weightlessness that you get when hacking in Python is largely due to the fact that the language works really, really hard to optimize this process. Go has given away this feeling of exhilaration, basically for nothing.
Hopefully the author now realizes that what Go gives up (only marginally) in "weightlessness" while developing is made up more than tenfold when maintaining code.
I honestly don't bat an eyelid anymore when I need to refactor Go code, even if I've forgotten to write tests[2]. It doesn't take anywhere near as long as refactoring Python takes me, and I don't worry as much about introducing logical errors (or worse, runtime exceptions).
[0] Incidentally, "generics" doesn't seem to be a common complaint among people who have actually programmed in Go for a moderate length of time, anecdotally.
[1] Yes, this is subjective.
[2] Yes, I know. Always write tests. But still.
While this will return immediately: