
Google Go: The Good, the Bad, and the Meh - ansible
http://blog.carlsensei.com/post/42828735125
======
tikhonj
The initial quote is a good summary about the thing I find must annoying about
Go. They constantly imply that programming research is useless in the real
world or at least impractical, and use that to ignore the last several decades
of progress. Then they try to turn ignoring research into a virtue!

It essentially presents a false dichotomy between programming research and
programming practice. This is particularly unfortunate because the most
practical and productive languages I know are the ones that embrace theory
like OCaml and Haskell. After all, most programming research is all about
being more productive in some way, and tends to approach the problem in a very
organized and disciplined fashion, usually building on past results.

~~~
vanderZwan
I'm not sure who "they" are, but certainly not the core development team, and
Samuel Tesla does not represent them. See for example Rob Pike saying how mind
blowing and inspiring Tony Hoare's CSP paper is, how everyone should read it
and how it inspired Go[1]. Another example is how Go's regexp implementation
has a solid mathematical foundation[2]. Now, those are two examples of quite
_old_ programming research being used to good effect in Go, so there is an
opening for criticism there. But in general I'm pretty sure the core go devs
don't have have anything against programming research nor try to create this
false dichotomy.

[1] <http://www.youtube.com/watch?v=3DtUzH3zoFo> [2]
<http://swtch.com/~rsc/regexp/regexp1.html>

~~~
binarycrusader
For those curious, Hoare's homepage and an electronic copy of the CSP Book can
be found here:

<http://research.microsoft.com/en-us/people/thoare/>

<http://www.usingcsp.com/>

------
stickfigure
I must be one of the idiot complainers he talks about, because his first "good
thing" annoys me right off the bat. If you want to change a private method to
public, you have to go through all your code and capitalize every use of it?

Yeah, I guess it could be handled with a refactoring IDE... if Go has one.

This feels like a throwback to hungarian notation. Names should just be names,
quit trying to cram code syntax into it. Besides, if you do have a competent
IDE, it can colorize private vs public names differently.

~~~
cdcarter
Not only is tptacek completely correct, the Go maintainers are completely
against code colorizing, so having visual markers in syntax is quite nice.

~~~
tptacek
They're against code colorizing?

~~~
seanmcdirmid
They mean syntax and semantic highlighting. It's mostly a generational thing
that goes along with 80 column line widths on amber terminals.

~~~
papsosouid
I wonder how much of that is older programmers being used to not having
highlighting, and how much is younger programmers having never tried
programming without it. I think the default assumption is that it is all old
people resisting change (hence the 80 columns amber terminals bit), but I'm a
younger anti-highlighting example. I am not old, I learned to code with
coloured syntax highlighting. I didn't realize how much of a hindrance it is
until after I had been programming for years and tried turning it off.

~~~
waterlesscloud
I'm old enough to have done both, and it doesn't matter much to me one way or
the other.

If anything, I think coloring is slightly helpful, but I'm fine without it.

------
lclarkmichalek
I'm really not crazy about the "import github.com/foobar/foo" thing. It seems
that systems like CPAN have an advantage in that a) you can roll your own
mirror to avoid using an untrusted network and b) should upstream change their
VCS etc, the go system requires changes to all files that import the affected
module. The go system also seems to ignore the problem of versioning
libraries, though I imagine there's probably some support for that in go get?

~~~
grey-area
I actually think the go solution to this problem is quite elegant (because it
also encapsulates info on where the dependencies come from), and preferable to
other package systems which have one point of failure or central package
repository.

If you want to roll your own mirror simply change github.com/foo to my
mirror.com/foo in your code. At least then you document the expected
dependency with the code itself and can remove it if required. It also lets
you very easily import a local package instead if you prefer. If the
maintainer changes the location of their package and you have not taken a copy
you might have to change your code, but this happens very rarely in my
experience and isn't a big issue.

Go doesn't have versioning for packages yet, and they will need to add this,
but that wouldn't be hard to add as an option to the current import scheme.

~~~
niggler
"If you want to roll your own mirror simply change github.com/foo to my
mirror.com/foo in your code"

This is very messy. If a mirror changes, you have to go back through all of
your source code and change all of the relevant imports.

I personally find the node.js/npm solution to the problem (separate the
dependency mapping for external resources, allow changes to those without
having to modify the source) to be more useful. It lets you swap local and
remote versions effortlessly and, using a private npm server, maintain
packages for a large internal network.

~~~
grey-area
_This is very messy. If a mirror changes, you have to go back through all of
your source code and change all of the relevant imports._

Have you run into real-life problems with this or is it more a hypothetical
issue?

You can use local package import paths instead if you prefer to manage your
dependencies separately (and have several different goroots too with different
sets of packages), or use DNS/hosts to manage where your private package
server domain points, there are lots of options which don't require
specification of a package server in one place.

------
DoubleCluster

      Let’s say I want to declare a pointer to a variable length
      array (what Python calls a list and Go calls a slice) of
      pointers to FooType objects:
    
         var foo *[]*FooType
    
      It reads very simply ...
    

What???? Not that it's better in other languages but this makes the article
feel like satire. It reads like "The Ugly" and "The Bad".

 _Aside: What's with the completely defective comment syntax on HN? Can anyone
give some hints on how to quote and how to escape the star character?_

edit: formatting, thanks spacemanaki

~~~
ajkjk
It's in comparison to the clockwise spiral rule:
<http://c-faq.com/decl/spiral.anderson.html>

~~~
tptacek
Which is such a baroque rule that it's probably not even a rule:
<http://news.ycombinator.com/item?id=5079787>

Go's declaration syntax is one of the best things about the language. I
thought it would take me forever to get used to, but within a day it was the
opposite: C feels backwards. It's especially excellent for references to
functions.

------
voidlogic
"Go doesn’t suppose the use of a #! on the starting line, which means you
can’t just use uncompiled files as utility scripts."

So the author wants to type "./foo.go" rather than "go run"? Why not just
build your executable, "go build", then you can run/move the resulting
executable ./foo.

This really doesn't seem like a big deal / why do I want to compile a utility
program every-time I run it?

~~~
orangethirty
Maybe for distribution purposes?

------
tptacek
Plus side: I had no idea about "go run foo.go" and it has changed my life.

Downside: couldn't read past "And what’s up with all the languages that claim
all you need are linked lists? I’m sorry, this is not 1958, and you are not
John McCarthy".

Did I miss anything amazing in the rest of the article? Thanks in advance.

~~~
coldtea
> _Did I miss anything amazing in the rest of the article? Thanks in advance._

Yes, you missed the fact that quitting articles or conversations because of
some remark (which could even be tongue-in-cheek) doesn't make you any smarter
and that "I stopped reading where he said" is not something to brag about.

~~~
niggler
"quitting articles or conversations because of some remark"

This is the problem with the internet and with political discourse in the 21st
century: as soon as someone says something that seems off-kilter, even if it
is technically correct, people stop listening/reading.

~~~
tptacek
It's not correct. He's making an allusion to lisp and imputing to it the
notion that everything is a linked list, which is not true. The article is a
comparative discussion of programming languages. Earlier, it calls critics of
the focal language in the article "idiots". That was OK with me while the
author had credibility. It simply lost credibility for me at the point where
it asserted that Lisp programmers don't use hash tables.

Apparently, I missed that Go could have, but didn't, support a syntax with
shell shebangs at the tops of files so it could be used for utility scripts. I
feel like I probably made the right call stopping where I did. ;)

~~~
coldtea
> _Earlier, it calls critics of the focal language in the article "idiots"._

No, he only calls critics of SPECIFIC aspects of the language (aspects
inconsequential and prone to bike-shedding) idiots.

> _It simply lost credibility for me at the point where it asserted that Lisp
> programmers don't use hash tables._

You weren't supposed to read his article as coming from a Lisp expert, seeing
that Lisp wasn't the main focus at all.

Heck, you weren't even expected to read the article as coming from a Go
expert. Just as an article from a guy that tried Go and shares what he thinks
of it.

> _It simply lost credibility for me at the point where it asserted that Lisp
> programmers don't use hash tables._

Would an article by Einstein on relativity "lose credibility" for you if he
makes some ignorant remarks about some aspects of mathematics in it?

~~~
klibertp
I thought about it some more and now I know why I was irritated by this
remark. I just felt this remark was exactly the same thing as some jerks
bulling a kid with glasses (or the fat one) in school.

There is that social situation where you're new to the group and don't really
know what's expected of you, what you should do. But you'd like to fit in.
It's after initial introductions and you know the group's members names, but
they're not that happy about you hanging around them. Some of them seem
hostile, others just indifferent. So naturally you want to avert their
attention and, if possible, show them that you have much in common.

And that's when this unpopular, fat or whatever, kid happens to fall just in
front of you. Of course you will be laughing, at the very least, and it's
quite possible that you'll be calling the kid an idiot with others. You know,
maybe you're not fully accepted into the group yet, but at least you're not
him. And you can laugh with your buddies, this matters too.

I find this remark exactly the same kind of thing. I read it as: "ok, so you
may use PHP, or maybe Java, that's all cool because hey, at least we're not
lispers! We're all one big, happy programming family (except for the lispers,
of course, who don't even know what a hash is)!"

I don't like this. I wrote "PHP" because it's a popular target of the same
bullying tactic. And Java, too, just in the other circles. I don't like it in
these cases either, despite the fact that I don't use either PHP nor Java and
frankly I don't think they're great. They may not be, but bullying is a bit
below what I want to see in a technical article - or in real life.

~~~
tptacek
In fairness, Lisp is the goofy looking kid everyone bullied in school who had
secretly trained at a Shaolin monastery.

------
echaozh
My personal grudge with Go is its sorting interface. You have to typedef
various kinds of slices and define methods for them. I mean, all Len() and
Swap() calls look exactly the same (at least in the sort package), it's such a
horrible duplication of code.

Also, the Less() method should not be defined for the slice types. They should
be defined for the types in the slices. Every sane language lets you define
comparing methods for types themselves, rather than bind them to the container
types, to honor some software principles.

Also, "err" is a surprisingly common name for variables even in the same
function. When it's previously defined, and the variable after it is not, the
":=" operator doesn't work (I seem to remember). Appending numbers to "err" is
ugly IMO. I don't mind no exceptions if not for this. Speaking of it, making
"err" a keyword or special global variable may be a good idea, like the
"errno" in C.

~~~
jff
You should be checking errors immediately after they are returned. Once you've
checked it, re-use the variable:

    
    
      x, err := f(a)
      if err != nil { // probably time to return from the func }
      y, err := g(x) // we have at least 1 new var, so := still works
      if err != nil { // handle }
      x, err = h(y) // since we're re-using both x and err, just use =
    

I've never appended a number to "err".

------
ggchappell
A nice article. And written in a thought-provoking manner. As I read it, I
think, "Do I agree that this is good/bad?"

A peeve: Just below the Accumulator Generator Challenge code, we find:

> The static typing adds a little noise, but it makes sense if you read it out
> loud: ....

It's not the _static_ typing that is noisy, but the _explicit_ typing.
Haskell, for example has static typing, but it can avoid this kind of "noise".

------
TheMagicHorsey
I don't think that the code the author listed for Paul Graham's Accumulator
Challenge is correct. The challenge specifically states that its for a number
not an integer, and its any incrementation, not addition. I'm not very
familiar with Go, but it seems like the Go solution is not as general as the
solutions in Lisp and other languages, where any operator and type can be used
with the accumulator function.

I'm sure there is probably some way to implement the same thing in Go using
duck typing. Just wanted to point out the difference though.

------
coldtea
I like his notion of "controversial with idiots".

~~~
michaelwww
I agree. I'm going to remind myself of this phrase next time I start to get
sucked into yet another endless and pointless discussion over personal
preference. One I've been using is Sweet Brown's "Ain't Nobody Got Time For
That" and it's been very effective. Now I have another phrase to deploy.

~~~
sigzero
Please don't. Calling someone an "idiot" just because they disagree with you?
Somehow that is is okay?

~~~
michaelwww
I don't say these things out loud.

------
lysa
The programming language is called Go, NOT Google Go.

~~~
svachalek
He only used it in the title... probably better as "Google's Go" or somesuch.
I can see why he did it though. Go ironically has to be the least Googleable
new language name since C++ (ok, until they changed the search syntax). It's
the name of a popular board game, a less popular programming language (Go!),
and an incredibly common verb.

~~~
lysa
What is wrong with "The Go Programming Language: The Good, the Bad, and the
Meh"?

