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

81–90 of 126 posts

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

#81

Post by dnu »

papsosouid wrote: post #74
coldtea wrote: post #60

Earlier quoted context omitted.

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…

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.

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

#83

Post by papsosouid »

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.

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

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

#85

Post by tptacek »

klibertp wrote: post #79
coldtea wrote: post #34

Earlier quoted context omitted.

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

In fairness, Lisp is the goofy looking kid everyone bullied in school who had secretly trained at a Shaolin monastery.

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

#86

Post by ansible »

BarkMore wrote: post #7
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…

The 'go get' sub-command is the only part of Go that interprets the import path as the location of a version control system repository. The use of the 'go get' sub-command is optional. You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import…

And what's nice about this is that if someone else uses your project and doesn't have their own mirrors for the repositories, he can use 'go get' to download the imports. And that's without making any changes to the codebase or build scripts.

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

#87

Post by DannyBee »

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…

1. Most languages allow multiple public modifiers, which can make humorously confusing experiences where you think something is private, but in reality, it's in the second public block.

In denser structures, particularly dense all-lowercase structures, this is easy to miss.

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

#88

Post by [deleted] »

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…

[deleted]

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

#89

Post by spacemanaki »

coldtea wrote: post #40
coldtea wrote: post #34

Earlier quoted context omitted.

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

Well, lots of important contributions in some fields have erroneous and ignorant remarks on other fields. If that (instead of careful consideration on their own merits and in their main focus) makes them "lose credibility", then well, I guess you should have more patience and tolerance for errors.

But it was an article about the merits of one programming language, in which the author made erroneous and ignorant remarks about another programming language, and other ignorant remarks about programming language features (mild ones like associating static typing with verbosity). It's not as if they made some flawed remarks about mathematics or electrical engineering, which truly are different fields. For me, it detracted from the author's credibility, because they apparently don't have a breadth of experience with programming languages, so why should I take their opinions about this one particular language very seriously?

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

#90

Post by benaiah »

papsosouid wrote: post #83
dnu wrote: post #81

Earlier quoted context omitted.

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.

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 the intensive stuff.

Your comment was a non sequitur from what dnu said. Please refrain from attacking arguments with straw men - they add nothing to the discussion

Edited for tone: s/Quit with the straw man arguments/Please refrain from attacking arguments with straw men/

Post reply on HN