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

51–60 of 126 posts

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

#51

Post by tptacek »

stickfigure wrote: post #49
tptacek wrote: post #21

Earlier quoted context omitted.

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

The two major virtues of case-based visibility:

1. It creates a coherent syntax for making names visible that works both for member variables and package variables; you don't ever have to wonder how to expose something, because you always do it just by making the name uppercase.

2. It allows readers to see at a glance without thinking whether a value is public --- it's public if it's a proper name.

In practice, Go struct definitions are extremely succinct, almost (at first) to a fault, because of decisions like this that eliminate syntax from the language. Compare a Go package to an equivalently functional Java package to see what I mean.

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

#52

Post by Jabbles »

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…

I don't think there would be a simpler way of describing a type as complex as "a pointer to a slice of pointers to FooType".

Simpler variables are declared as

    var a int
or with type inference:

    var a = 10

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

#53

Post by snprbob86 »

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're are changing a...

...private to public:

The only references are in your package. They can be found trivially with ack or grep.

...private mutable variable to public:

You want to inspect all usages anyway to ensure that you're not violating the public invariant.

...private function to public:

You want to inspect all usages anyway in case you'd prefer to call an internal version of the function without the same preamble, such as argument defaulting or validation logic. If you change 'foo' to 'Foo', you can leave 'foo' around and just have 'Foo' call it.

...public to private:

You need to find all the external references anyway to eliminate them. Since the references are capitalized, it's easy to find them with a grep or ack. You won't get lots of false positives from locals that are named without a capital.

;

Personally, I prefer languages that let you bend the rules when you need to, but I also work with small and skilled teams on largely exploratory projects. If I were working on a larger and ever evolving corporate team, I'd be all over Go. They have made some excellent design trade offs for that audience; ie Google's internal usage.

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

#54

Post by spacemanaki »

Jabbles wrote: post #44
spacemanaki wrote: post #39

Earlier quoted context omitted.

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.

Well his personal taste likely informed the design decision to use capitalization to confer some semantics for a variable.

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

#55

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

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

#56

Post by tptacek »

spacemanaki wrote: post #54
Jabbles wrote: post #44

Earlier quoted context omitted.

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

Well his personal taste likely informed the design decision to use capitalization to confer some semantics for a variable.

I'm not sure I see how capital letters make a language harder to syntax highlight.

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

#57

Post by michaelwww »

sigzero wrote: post #42
michaelwww wrote: post #19

Earlier quoted context omitted.

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?

I don't say these things out loud.

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

#58

Post by papsosouid »

seanmcdirmid wrote: post #38
tptacek wrote: post #31

Earlier quoted context omitted.

They're against code colorizing?

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

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.

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

#59

Post by lclarkmichalek »

NateDad wrote: post #50
lclarkmichalek wrote: post #30

Earlier quoted context omitted.

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.

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.

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

#60

Post by coldtea »

tptacek wrote: post #46
coldtea wrote: post #36

Earlier quoted context omitted.

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

To be frank, no. The article pretty much sums up my conclusions too.

I generally like Go, but dislike some of the design decisions (like the lack of Generics, or the special casing of a few select structures). Not much sold on the error handling either.

But those would be minor gripes if it had real good performance, which it does not, considering it's a statically typed, compiled language. It's been around 2x faster than Python in most of my uses (which don't involve parallelism), which doesn't really tempt to use Go over Python. If it could get closer to C++/Java performance it would be nice.

I wish Google had devoted some hardcore compiler guys like it did with Dart and V8 on it, because the current old-school team, while very good at systems programming and with a long history, is not really up to it for a 2013 language.

In the meantime, I wait to see what happens with Rust.

Post reply on HN