Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.carlsensei.com

Post reply on HN
Print view View original

41–50 of 126 posts

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

#41

Post by Jabbles »

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…

go through all your code and capitalize every use of it

Due to the ease of parsing go, it comes with a tool called gofix, designed for exactly this kind of change.

http://golang.org/cmd/fix/

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

#42

Post by sigzero »

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.

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

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

#43

Post by rsaarelm »

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…

If you want to change private bar to public Bar from package foo, the standard trick is to use gofmt's rewrite option and run "gofmt -r 'foo.bar -> foo.Bar' -w *.go".

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

#44

Post by Jabbles »

spacemanaki wrote: post #39
tptacek wrote: post #31

Earlier quoted context omitted.

They're against code colorizing?

Well Rob Pike did call it "juvenile" and compared it to those colored rods that are used to teach children how to count. http://news.ycombinator.com/item?id=5125958

He was joking.

But still, it's his personal taste to not use it.

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

#45

Post by spacemanaki »

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…

Your best bet with code in comments is to indent:

  var foo *[]*FooType
http://news.ycombinator.com/formatdoc

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

#46

Post by tptacek »

coldtea wrote: post #36
coldtea wrote: post #20

Earlier quoted context omitted.

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

What do you think of Go so far? (I've written ~10kloc).

Did this article in any way change your mind about it?

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

#47

Post by sesteel »

cdcarter wrote: post #29
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.

I agree that syntax highlighting is useful, but people value different things. Whether a language creator likes syntax highlighting or not says nothing about the quality of the language they created.

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

#48

Post by NateDad »

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 all code is read in an IDE. Also, most IDEs don't color names differently at call sites. For example:

a = foo.Bar()

You know Bar is a public function of foo. It's not hungarian notation because you're not adding otherwise-nonsense characters to the beginning of an identifier, which would make them longer and harder to read.

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

#49

Post by stickfigure »

tptacek wrote: post #21
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 wr…

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.

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

#50

Post by NateDad »

lclarkmichalek wrote: post #30
zemo wrote: post #17

Earlier quoted context omitted.

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

That's a good thing.
Post reply on HN