11 ms·

Google Go: The Good, the Bad, and the Meh

95 points by ansible 14y ago

voidlogic 14y ago
"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?
- Evbn 14y ago
  Go run compiled as often each #!python. The runner can cache whatever it wants. But someone could write shebang-go wrapper to implement this functionality, but a modification to Unix would be needed, since shebang is a magic hack on the '#' character, not configurable,IIRC
- orangethirty 14y ago
  Maybe for distribution purposes?
lclarkmichalek 14y ago
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?
- BarkMore 14y ago
  The 'go get' sub-command is the only part of Go that interprets the import path as the location of a version control system repository. The use of the 'go get' sub-command is optional. You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import path, all of the other go tools will work with the code.
  - ansible 14y ago
    And what's nice about this is that if someone else uses your project and doesn't have their own mirrors for the repositories, he can use 'go get' to download the imports. And that's without making any changes to the codebase or build scripts.
- grey-area 14y ago
  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 14y ago
    "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 14y ago
      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.
  - BarkMore 14y ago
    "If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" Instead of changing the code, use a version control command to clone your repository mirror to your workspace.
- zemo 14y ago
  it forces the package names to be globally unique, by piggybacking off of DNS. If you own "lclarkmichalek.com" you can put up a server and then have "import lclarkmichalek.com/foobar/foo" if you really want to.
  - lclarkmichalek 14y ago
    That's a point I hadn't thought of. Though on the negative side, it does make it significantly harder to create a true "drop in replacement" that other languages have (i.e. where a library provides a replacement of another library without requiring any modification to the source code of an application using that library).
    - NateDad 14y ago
      That's a good thing.
      - lclarkmichalek 14y ago
        How so? I can think of a couple of examples where libraries have needed to be replaced and it's only because their replacements were transparently compatible that the replacement was possible without major pain all around.
    - chimeracoder 14y ago
      You're still going to need to recompile, because Go programs are all statically linked. Replacing the imports is pretty easy, though - because Go is so draconian about certain elements of formatting and style (including restrictions on imports), it's relatively straightforward to migrate code like this. (The 'go fix' tool is an even better example of the power that such an opinionated compiler provides as its tradeoff)
deleted 14y ago
[deleted]
tptacek 14y ago
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 14y ago
  >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.
  - tptacek 14y ago
    Did I miss anything else? This point isn't very interesting to me.
    - coldtea 14y ago
      Well, it's impossible to tell without knowing what's interesting to you. That said, I think the above point is more generic and important than anything Go specific the article could say.
      - tptacek 14y ago
        Never give up hope! One of these days, you'll leave a comment about people's refusal to read blog posts all the way through and by doing so change the world. Do you write a lot of Go code?
      - coldtea 14y ago
        >Never give up hope! One of these days, you'll leave a comment about people's refusal to read blog posts all the way through and by doing so change the world. I agree. People having patience with other people and going through their argument thoroughly is much more important than someone complaining about another's remarks on his language of choice. Of Go code I've written around 1000-1500 lines, merely to check the language out (a small server app and a logging utility). That said, Go itself was never the focus of this subthread.
DoubleCluster 14y ago
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 14y ago
  It's in comparison to the clockwise spiral rule: http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html
  - niggler 14y ago
    Cool site: http://cdecl.org/ http://cdecl.org/
  - DoubleCluster 14y ago
    Right, it may be a tiny bit better but it's still not easy to read. The only way to make it actually readable is with typedefs.
  - tptacek 14y ago
    Which is such a baroque rule that it's probably not even a rule: http://news.ycombinator.com/item?id=5079787 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.
- stevvooe 14y ago
  How so? There is a well thought out reason for this ordering [1], and it has taken hold in many other languages, such as rust and scala. Compare with the complexity of c or c++ type signatures. [1] http://golang.org/doc/articles/gos_declaration_syntax.html http://golang.org/doc/articles/gos_declaration_syntax.html
coldtea 14y ago
I like his notion of "controversial with idiots".
- michaelwww 14y ago
  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.
  - coldtea 14y ago
    I guess this "controversial with idiots" is a similar concept to bike-shedding, yac shaving...
  - sigzero 14y ago
    Please don't. Calling someone an "idiot" just because they disagree with you? Somehow that is is okay?
    - michaelwww 14y ago
      I don't say these things out loud.
- craftkiller 14y ago
  http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
  - coldtea 14y ago
    I also don't believe in "one size fits all" counter-arguments. Sometimes an ad-hominen is the proper thing to say. And in particular cases any of the so-called "logical fallacies" can be very much true and useful. For example, we use the "argument by authority" every-time we trust our doctor instead of our friend's intuition, and I'm perfectly fine with that. An "argument by authority" might not be a perfect tool in 100% of the cases, but it's a perfectly good guideline when we don't have time to go through the details of the matter ourselves. The old-wives-tales on "logical fallacies" point at their less than 100% accuracy and come to the wrong conclusion that they are bad and thus useless.
stickfigure 14y ago
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.
- tptacek 14y ago
  Rob Pike's Go FAQ says that this is one of their favorite features about Go, and I agree; it's how I've been writing C code since 1995. So, I mean, if conformance to my C programming style guide matters, YOU LOSE THE ARGUMENT! :) I'd also contend that no language makes changing the visibility of a variable completely painless. You're fixating on the one case where you can change the token "private" to "public" and write new client code for a class. But you're ignoring public->private, which is a breaking change no matter what syntax you use; you're also ignoring the fact that moving a variable out of or into a class (for instance with class statics) is breaking no matter what you do. As this article points out, the major win for simply using case to signal this is that the language gets to dispense with fussiness about where variables are; you can just put them in packages when they make sense. It's all tradeoffs, of course. It's certainly your prerogative to be annoyed by design decisions in Go! I'm extremely annoyed by the import use requirement and refuse to not be annoyed by it no matter how many times Rob Pike and Russ Cox say it prevents bugs.
  - stickfigure 14y ago
    If I'm fixated on changing private -> public, that's because it's a common case. I doubt I'm alone with a programming approach of "start with everything private and expose public behavior only as necessary". More philosophically, I have to wonder what the benefit of this capitalization scheme is. Just to avoid typing 'public'? Hardly seems worthwhile. To make it obvious when reading code? This is the same argument for hungarian notation, which even Redmond has abandoned. IDEs for static languages like Go are perfectly capable of presenting identifiers appropriately - if indeed public/private is really what you want to call attention to. I admit that I've not done more than dabble in Go, but I'm somewhat skeptical of this last point. Of all the IDEs I have used for various static languages, I have yet to see any that visually distinguish public vs private identifiers. If calling attention to this distinction was so important that it should be built into the language, I would expect it to be common practice in IDE formatting already.
echaozh 14y ago
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 14y ago
  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".
lysa 14y ago
The programming language is called Go, NOT Google Go.
- svachalek 14y ago
  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 14y ago
    What is wrong with "The Go Programming Language: The Good, the Bad, and the Meh"?
tikhonj 14y ago
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 14y ago
  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 http://www.youtube.com/watch?v=3DtUzH3zoFo [2] http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html
  - binarycrusader 14y ago
    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://research.microsoft.com/en-us/people/thoare/ http://www.usingcsp.com/ http://www.usingcsp.com/
- tesla 14y ago
  It is rather surreal to see myself quoted. Especially something I wrote on my blog that I didn't think anybody actually reads. Allow me to provide some context [1] for the quote. Shortly after the language was released, somebody was ranting [2] about how Go was not innovative at all in comparison to other modern languages. I was not suggesting that programming research is useless and that we should ignore several decades of progress. I was, rather, saying that Go was applying those several decades of progress to systems programming to produce a more modern version of C. Here is the whole paragraph that quote was lifted from: "The point the author fails to see is that Go is not meant to innovate programming theory. It’s meant to innovate programming practice. This is an upgrade to C. It’s a language that applies the innovations of the last thirty years to the systems world, where the state of the art is still portable assembler. So no, the language isn’t introducing brilliant new ideas. It’s taking tested old ideas, and introducing them into a new arena." [1] http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-experimental.html http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-exp... [2] http://monoc.mo.funpic.de/go-rant/ http://monoc.mo.funpic.de/go-rant/
ggchappell 14y ago
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 14y ago
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.

95 points by ansible 14y ago

"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?

Evbn 14y ago
Go run compiled as often each #!python. The runner can cache whatever it wants. But someone could write shebang-go wrapper to implement this functionality, but a modification to Unix would be needed, since shebang is a magic hack on the '#' character, not configurable,IIRC
orangethirty 14y ago
Maybe for distribution purposes?

lclarkmichalek 14y ago

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?

BarkMore 14y ago
The 'go get' sub-command is the only part of Go that interprets the import path as the location of a version control system repository. The use of the 'go get' sub-command is optional. You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import path, all of the other go tools will work with the code.
- ansible 14y ago
  And what's nice about this is that if someone else uses your project and doesn't have their own mirrors for the repositories, he can use 'go get' to download the imports. And that's without making any changes to the codebase or build scripts.
grey-area 14y ago
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 14y ago
  "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 14y ago
    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.
- BarkMore 14y ago
  "If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" Instead of changing the code, use a version control command to clone your repository mirror to your workspace.
zemo 14y ago
it forces the package names to be globally unique, by piggybacking off of DNS. If you own "lclarkmichalek.com" you can put up a server and then have "import lclarkmichalek.com/foobar/foo" if you really want to.
- lclarkmichalek 14y ago
  That's a point I hadn't thought of. Though on the negative side, it does make it significantly harder to create a true "drop in replacement" that other languages have (i.e. where a library provides a replacement of another library without requiring any modification to the source code of an application using that library).
  - NateDad 14y ago
    That's a good thing.
    - lclarkmichalek 14y ago
      How so? I can think of a couple of examples where libraries have needed to be replaced and it's only because their replacements were transparently compatible that the replacement was possible without major pain all around.
  - chimeracoder 14y ago
    You're still going to need to recompile, because Go programs are all statically linked. Replacing the imports is pretty easy, though - because Go is so draconian about certain elements of formatting and style (including restrictions on imports), it's relatively straightforward to migrate code like this. (The 'go fix' tool is an even better example of the power that such an opinionated compiler provides as its tradeoff)

deleted 14y ago

[deleted]

tptacek 14y ago

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 14y ago
>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.
- tptacek 14y ago
  Did I miss anything else? This point isn't very interesting to me.
  - coldtea 14y ago
    Well, it's impossible to tell without knowing what's interesting to you. That said, I think the above point is more generic and important than anything Go specific the article could say.
    - tptacek 14y ago
      Never give up hope! One of these days, you'll leave a comment about people's refusal to read blog posts all the way through and by doing so change the world. Do you write a lot of Go code?
    - coldtea 14y ago
      >Never give up hope! One of these days, you'll leave a comment about people's refusal to read blog posts all the way through and by doing so change the world. I agree. People having patience with other people and going through their argument thoroughly is much more important than someone complaining about another's remarks on his language of choice. Of Go code I've written around 1000-1500 lines, merely to check the language out (a small server app and a logging utility). That said, Go itself was never the focus of this subthread.

DoubleCluster 14y ago

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 14y ago
It's in comparison to the clockwise spiral rule: http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html
- niggler 14y ago
  Cool site: http://cdecl.org/ http://cdecl.org/
- DoubleCluster 14y ago
  Right, it may be a tiny bit better but it's still not easy to read. The only way to make it actually readable is with typedefs.
- tptacek 14y ago
  Which is such a baroque rule that it's probably not even a rule: http://news.ycombinator.com/item?id=5079787 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.
stevvooe 14y ago
How so? There is a well thought out reason for this ordering [1], and it has taken hold in many other languages, such as rust and scala. Compare with the complexity of c or c++ type signatures. [1] http://golang.org/doc/articles/gos_declaration_syntax.html http://golang.org/doc/articles/gos_declaration_syntax.html

coldtea 14y ago

I like his notion of "controversial with idiots".

michaelwww 14y ago
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.
- coldtea 14y ago
  I guess this "controversial with idiots" is a similar concept to bike-shedding, yac shaving...
- sigzero 14y ago
  Please don't. Calling someone an "idiot" just because they disagree with you? Somehow that is is okay?
  - michaelwww 14y ago
    I don't say these things out loud.
craftkiller 14y ago
http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
- coldtea 14y ago
  I also don't believe in "one size fits all" counter-arguments. Sometimes an ad-hominen is the proper thing to say. And in particular cases any of the so-called "logical fallacies" can be very much true and useful. For example, we use the "argument by authority" every-time we trust our doctor instead of our friend's intuition, and I'm perfectly fine with that. An "argument by authority" might not be a perfect tool in 100% of the cases, but it's a perfectly good guideline when we don't have time to go through the details of the matter ourselves. The old-wives-tales on "logical fallacies" point at their less than 100% accuracy and come to the wrong conclusion that they are bad and thus useless.

stickfigure 14y ago

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.

tptacek 14y ago
Rob Pike's Go FAQ says that this is one of their favorite features about Go, and I agree; it's how I've been writing C code since 1995. So, I mean, if conformance to my C programming style guide matters, YOU LOSE THE ARGUMENT! :) I'd also contend that no language makes changing the visibility of a variable completely painless. You're fixating on the one case where you can change the token "private" to "public" and write new client code for a class. But you're ignoring public->private, which is a breaking change no matter what syntax you use; you're also ignoring the fact that moving a variable out of or into a class (for instance with class statics) is breaking no matter what you do. As this article points out, the major win for simply using case to signal this is that the language gets to dispense with fussiness about where variables are; you can just put them in packages when they make sense. It's all tradeoffs, of course. It's certainly your prerogative to be annoyed by design decisions in Go! I'm extremely annoyed by the import use requirement and refuse to not be annoyed by it no matter how many times Rob Pike and Russ Cox say it prevents bugs.
- stickfigure 14y ago
  If I'm fixated on changing private -> public, that's because it's a common case. I doubt I'm alone with a programming approach of "start with everything private and expose public behavior only as necessary". More philosophically, I have to wonder what the benefit of this capitalization scheme is. Just to avoid typing 'public'? Hardly seems worthwhile. To make it obvious when reading code? This is the same argument for hungarian notation, which even Redmond has abandoned. IDEs for static languages like Go are perfectly capable of presenting identifiers appropriately - if indeed public/private is really what you want to call attention to. I admit that I've not done more than dabble in Go, but I'm somewhat skeptical of this last point. Of all the IDEs I have used for various static languages, I have yet to see any that visually distinguish public vs private identifiers. If calling attention to this distinction was so important that it should be built into the language, I would expect it to be common practice in IDE formatting already.

echaozh 14y ago

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 14y ago
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".

lysa 14y ago

The programming language is called Go, NOT Google Go.

svachalek 14y ago
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 14y ago
  What is wrong with "The Go Programming Language: The Good, the Bad, and the Meh"?

tikhonj 14y ago

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 14y ago
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 http://www.youtube.com/watch?v=3DtUzH3zoFo [2] http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html
- binarycrusader 14y ago
  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://research.microsoft.com/en-us/people/thoare/ http://www.usingcsp.com/ http://www.usingcsp.com/
tesla 14y ago
It is rather surreal to see myself quoted. Especially something I wrote on my blog that I didn't think anybody actually reads. Allow me to provide some context [1] for the quote. Shortly after the language was released, somebody was ranting [2] about how Go was not innovative at all in comparison to other modern languages. I was not suggesting that programming research is useless and that we should ignore several decades of progress. I was, rather, saying that Go was applying those several decades of progress to systems programming to produce a more modern version of C. Here is the whole paragraph that quote was lifted from: "The point the author fails to see is that Go is not meant to innovate programming theory. It’s meant to innovate programming practice. This is an upgrade to C. It’s a language that applies the innovations of the last thirty years to the systems world, where the state of the art is still portable assembler. So no, the language isn’t introducing brilliant new ideas. It’s taking tested old ideas, and introducing them into a new arena." [1] http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-experimental.html http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-exp... [2] http://monoc.mo.funpic.de/go-rant/ http://monoc.mo.funpic.de/go-rant/

ggchappell 14y ago

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 14y ago

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.