Google Go: The Good, the Bad, and the Meh • Hacker News Board

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

#21

Post by tptacek » Mon, Feb 11, 2013, 4:18 PM UTC

stickfigure wrote: post #13

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…

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.

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

#22

Post by coldtea » Mon, Feb 11, 2013, 4:18 PM UTC

michaelwww wrote: post #19

coldtea wrote: post #10

I like his notion of "controversial with idiots".

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.

I guess this "controversial with idiots" is a similar concept to bike-shedding, yac shaving...

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

#23

Post by stevvooe » Mon, Feb 11, 2013, 4:20 PM UTC

DoubleCluster wrote: post #9

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

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

#24

Post by niggler » Mon, Feb 11, 2013, 4:20 PM UTC

ajkjk wrote: post #18

DoubleCluster wrote: post #9

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…

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

Cool site: http://cdecl.org/

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

#25

Post by tptacek » Mon, Feb 11, 2013, 4:21 PM UTC

niggler wrote: post #16

coldtea wrote: post #12

Earlier quoted context omitted.

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

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

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. ;)

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

#26

Post by BarkMore » Mon, Feb 11, 2013, 4:21 PM UTC

grey-area wrote: post #11

lclarkmichalek wrote: post #3

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 probab…

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 ca…

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

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

#27

Post by tptacek » Mon, Feb 11, 2013, 4:23 PM UTC

coldtea wrote: post #20

tptacek wrote: post #15

Earlier quoted context omitted.

Did I miss anything else? This point isn't very interesting to me.

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.

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?

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

#28

Post by incision » Mon, Feb 11, 2013, 4:23 PM UTC

tptacek wrote: post #8

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.

Too cool to finish reading an article that already "changed your life" so you ask some plebe to give you the tl;dr.

Grow up.

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

#29

Post by cdcarter » Mon, Feb 11, 2013, 4:23 PM UTC

stickfigure wrote: post #13

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…

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

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

#30

Post by lclarkmichalek » Mon, Feb 11, 2013, 4:24 PM UTC

zemo wrote: post #17

lclarkmichalek wrote: post #3

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 probab…

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.

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