

How I Learned to Stop Worrying and Love Golang - manu3000
http://corte.si/posts/code/go/golang-practicaly-beats-purity/index.html

======
dlsspy
This is very much false:

While this will return immediately:

    
    
        v, ok := <- c

~~~
chimeracoder
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.

~~~
dlsspy
"<-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. :)

------
dlsspy
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.

------
chimeracoder
> 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.

