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

91–100 of 126 posts

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

#91

Post by tikhonj »

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.

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

#92

Post by bcoates »

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.

Apparently "operator overloading, function/method overloading, [and] keyword arguments" are "bad for performance" so it's OK that Go doesn't have them.

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

#93

Post by papsosouid »

benaiah wrote: post #90
papsosouid wrote: post #83

Earlier quoted context omitted.

I think programs that are 90% C and 10% python do constitute "unusual use cases".

That would be unusual, but 80% of a program's performance is generally tied up in 20% of its code. If you can replace the 20% with a couple widely-used C libraries, then you get vastly improved performance without actually having to write much C. In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do…

>80% of a program's performance is generally tied up in 20% of its code

I've never seen any evidence to support this truthy sounding statement. In fact, my experience has been that it only holds true occasionally, and only for the very first initial profiling, seeing that some huge performance no-no was made. Once that is fixed, you have a pretty flat profile, with "the language is just slow" as your explanation, and no recourse.

>Your comment was a non sequitur from what dnu said.

No it wasn't. He responded to what I said. How could re-iterating what I said be a non-sequitur? Read the thread, I said python being only twice as slow as go "for my uses" would indicate some very unusual uses.

>In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do the intensive stuff.

No, in the cases you want to put forth as representative because they support your belief that slow languages are good enough. Most applications don't have a convenient "intensive stuff" to do in C. Most applications are like django, just generally slow all over because they are written in a slow language.

>Quit with the straw man arguments - they add nothing to the discussion.

Neither do unwarranted accusations of straw man arguments.

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

#94

Post by jff »

echaozh wrote: post #55

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

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

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

#95

Post by CJefferson »

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…

Actually, I find public->private is not a breaking change, because before I do a 'public->private' change, I first remove all the public calls. Therefore, all I have left to do is to check the in-class calls.

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

#96

Post by coldtea »

craftkiller wrote: post #82
coldtea wrote: post #10

I like his notion of "controversial with idiots".

http://en.wikipedia.org/wiki/Ad_hominem

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.

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

#97

Post by chimeracoder »

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

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)

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

#98

Post by bad_user »

mattmanser wrote: post #72
stickfigure wrote: post #49

Earlier quoted context omitted.

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?

Python - everything is public, so a convention is required to make developers distinguish between public and intended-private-but-still-public (e.g. do not touch).

C# - I don't really know what's common practice in C#, but without a really good reason placing underscore in front of private properties would be really, really stupid.

On Python again - I used Python everyday for the last 3 years and I hate the whitespace convention. It's not because I have to use significant whitespace, but this syntax is the number one reason for why the language never got anonymous code-blocks. And I love the lightweight syntax, but looking at other lightweight languages, working with significant whitespace is just not worth it if it disallows such a useful and common feature.

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

#99

Post by ansible »

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…

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 haven't seen anything in the language design that would make further speed improvements especially difficult, so I'm hopeful that the speed of compiled code will improve as time goes by. I agree with you that if they get some more talented developers, that would really help.

As an aside, after reading about the LuaJIT trace compiler implementation, I am quite intimidated by the amount of knowledge and skill that is needed to write really fast code on modern processors (even embedded ones).

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

#100

Post by igouy »

dnu wrote: post #81
papsosouid wrote: post #74

Earlier quoted context omitted.

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

That benchmark is for algorithms implemented in pure Python and in pure Go. But for real projects, a Python programmer might use several libraries which are written in C.

>> That benchmark is for algorithms implemented in pure Python and in pure Go Note that papsosouid needed to add the restriction "on benchmarks actually written in python instead of C" to avoid mentioning the 2 tasks where Python is shown as faster than Go ;-)
Post reply on HN