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

71–80 of 126 posts

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

#71

Post by tptacek »

stickfigure wrote: post #66
tptacek wrote: post #51

Earlier quoted context omitted.

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

Please convince me this is a good idea. #1 does not seem to be a real issue. Most similar languages have the common, popularly understood, and easily-remembered keyword "public". Whereas capitalization is an exotic special rule that must be learned. If "you don't ever have to wonder how to expose something" is an important measure, I think Go is at a disadvantage here - especially if you want your code to be read by…

I think you have to look at this in the context of the whole language. Go doesn't just not have a "public" keyword. It also doesn't have classes. The way Go structures code is optimized to maximize code reuse while minimizing declarative syntax. So Go has an integrated package system (unlike C++) because that helps you build modules of code that can easily be used across projects, but doesn't have inheritance (unlike C++) because that is a feature that is less about reusing code and more about modeling systems.

I'm sure you've had the experience of working with libraries in other languages where the designer couldn't or didn't make up their mind about whether to expose capabilities as free functions or classes that needed instantiation, or, worse, exposed factories and singletons to get around their discomfort with simple functions.

Go sidesteps this problem. I found it helpful to think of it not as removing the "public" keyword from struct defs, but as creating a mechanism to "promote" functions and variables in packages --- something that would feel very shady in C++, but doesn't in Go. As a result, a lot of packages do The Simplest Thing That Could Possibly Work and just expose simple functions. The result is usually refreshingly clear.

I agree with you about error handling; Go's error handling makes its source code (though not its library interfaces) fussy and hard to read.

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

#72

Post by mattmanser »

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…

Most programming languages use these conventions informally. For example:

Javascript - always capitalize classes

Python - underscore before private properties

C# - underscore in front of class level private properties

Python upgraded the whitespace convention to meaningful whitespace, why shouldn't Go upgrade the naming convention?

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

#73

Post by grey-area »

niggler wrote: post #14
grey-area wrote: post #11

Earlier quoted context omitted.

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

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.

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

#74

Post by papsosouid »

coldtea wrote: post #60
tptacek wrote: post #46

Earlier quoted context omitted.

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…

>It's been around 2x faster than Python in most of my uses

You must have some very unusual uses for that to be true. The computer language shootout isn't perfect, but it includes a variety of uses, and python is at best 5 times slower than go on benchmarks actually written in python instead of C, and 20-30 times slower for most of them.

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Go is in the same performance field as java, haskell, scala, lisp, C#, etc. The 2-5x slower than C group. Python is in the same field as php, perl, ruby, etc. They are 30-50x slower than C. That's a huge difference.

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

#75

Post by stickfigure »

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.

FWIW, this makes me seriously question the sanity of the Go designers. I spent my college career writing code on VT100s, I'm never going back. I am much more productive with an IDE, and the patterns of colors and fonts are a big part of that.

I wonder if Rob Pike is colorblind.

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

#76

Post by svachalek »

Jabbles wrote: post #69
smosher wrote: post #62

Earlier quoted context omitted.

Two examples come to mind: [FooType] and: Slice If you think you must, apply sigils. The position of the brackets in the Go version is atypically bad for readability.

I don't understand. Where do your examples say they're pointers? How would you express this using your first syntax? *[4]*FooType

The first is or could be Haskell. The length of a list is not part of its type. The second looks like Java, ditto there (although built-in arrays have a different syntax).

Haskell does not have mutability at all and thus no "pointers". In Java the insides of containers are mutable so you'd have to add an outer array or list. In either case though you don't need pointers to simply pass things around as you do in C (I don't know about Go).

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

#77

Post by klibertp »

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.

I stopped reading at the exact same place and I'm still considering going back to the article to read the rest of it. I don't know, maybe later - which means that I probably won't read it.

Calling people who disagree with a specific coding convention idiots was irritating, but it at least had a bit of merit - namely that 'readability counts' and that the code is more readable if it's written in consistent style.

The remark about linked lists in Lisps is both irritating and untrue. If even Schemes (I know. I just wrote a cute, little, hobby project in Racket and I used a list twice (by accident)) routinely deal with vectors and hashes then I can only imagine how many different builtin datastructures have CL (or Clojure) programmers at their disposal.

It probably was meant as a joke. Ok - it just isn't the sense of humor I share, that's all.

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

#78

Post by coldtea »

Jabbles wrote: post #67
coldtea wrote: post #63

Earlier quoted context omitted.

I find I tend to disagree with most of the design decisions of Rob Pike, from minor (like that one), to the more important like the bogus emphasis on compilation speed and the half-baked excuses on not having Generics. If it was someone else on board in Go, we might have had a vastly better language.

That's ok. Nothing wrong with disagreeing. But it sounds like you don't like Go. As you say, it's heavily influenced by Rob's personal vision of how things should be done. Plan 9, unicode, refusal to complicate the parser etc. They're all decisions that have given Go its (IMO) unique feel. Without Rob we'd have a vastly different language, certainly.

>But it sounds like you don't like Go.

Well, I like large parts of it though. From major stuff, like the implicit interfaces, the syntax for having methods on structs etc, the simple C like syntax, to minor stuff like the capital letter for exports and gofmt for one and only one formatting. And the promise (which is not yet a reality) of a fast, memory efficient, statically compiled language.

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

#79

Post by klibertp »

coldtea wrote: post #34
tptacek wrote: post #25

Earlier quoted context omitted.

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

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

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.

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

#80

Post by smosher »

Jabbles wrote: post #69
smosher wrote: post #62

Earlier quoted context omitted.

Two examples come to mind: [FooType] and: Slice If you think you must, apply sigils. The position of the brackets in the Go version is atypically bad for readability.

I don't understand. Where do your examples say they're pointers? How would you express this using your first syntax? *[4]*FooType

Where do your examples say they're pointers?

They don't, it's inferred in my examples. Like I said, if you need them, you can use whatever sigils you want. They can go in front of the types as usual.

How would you express this using your first syntax?

I wouldn't. That syntax is decidedly inappropriate for vectors that incorporate length into the type.

Post reply on HN