Live data from Hacker News

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

blog.carlsensei.com

111–120 of 126 posts

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

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

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.

That's great for you, but I suppose you've never published a module on CPAN, a ruby gem, a Python... egg (man, that's a weird convention). As soon as someone else depends on your module - and Go is very modular, this behavior is encouraged - suddenly it's an exercise in putting fluids back into containers, or whatever they say.

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

#112
post #34
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…

"You weren't supposed to read his article as coming from a Lisp expert, seeing that Lisp wasn't the main focus at all."

Then why did he make snide, ignorant allusion to Lisp?

"You shouldn't hold that comment against him; he doesn't know what he's talking about and you shouldn't expect him to" is an odd defense.

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

#113
post #91

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

I'm not sure who "they" are, but certainly not the core development team, and Samuel Tesla does not represent them. See for example Rob Pike saying how mind blowing and inspiring Tony Hoare's CSP paper is, how everyone should read it and how it inspired Go[1]. Another example is how Go's regexp implementation has a solid mathematical foundation[2]. Now, those are two examples of quite old programming research being u…

For those curious, Hoare's homepage and an electronic copy of the CSP Book can be found here:

http://research.microsoft.com/en-us/people/thoare/

http://www.usingcsp.com/

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

#114
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.

It's not a generational thing.

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

#115
post #84

The programming language is called Go, NOT Google Go.

He only used it in the title... probably better as "Google's Go" or somesuch. I can see why he did it though. Go ironically has to be the least Googleable new language name since C++ (ok, until they changed the search syntax). It's the name of a popular board game, a less popular programming language (Go!), and an incredibly common verb.

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

#116
post #34
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…

The comparison with Einstein is a bit of a stretch. Surely Einstain has a fair aomount of credibility going in.

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

#117

Earlier quoted context omitted.

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

Sometimes paradigm shifts are just that and indicate generational pivots. Ask an electrician today to do some wiring without color coded wires and they'll think you are batsh*t crazy, but it probably wouldn't have been so crazy a hundred or so years ago when color wasn't viable. The same thing applies to code; these people grew up programming before color monitors were much of an option.

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

#118
post #91

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

It is rather surreal to see myself quoted. Especially something I wrote on my blog that I didn't think anybody actually reads.

Allow me to provide some context [1] for the quote. Shortly after the language was released, somebody was ranting [2] about how Go was not innovative at all in comparison to other modern languages. I was not suggesting that programming research is useless and that we should ignore several decades of progress. I was, rather, saying that Go was applying those several decades of progress to systems programming to produce a more modern version of C. Here is the whole paragraph that quote was lifted from:

"The point the author fails to see is that Go is not meant to innovate programming theory. It’s meant to innovate programming practice. This is an upgrade to C. It’s a language that applies the innovations of the last thirty years to the systems world, where the state of the art is still portable assembler. So no, the language isn’t introducing brilliant new ideas. It’s taking tested old ideas, and introducing them into a new arena."

[1] http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-exp...

[2] http://monoc.mo.funpic.de/go-rant/

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

#119
post #109
post #92

Earlier quoted context omitted.

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

For performance of compilation . Go compiles crazy fast -- think two seconds for complete compiler and runtime on a notebook. This provides for rapid hack-compile-debug iterations. http://www.youtube.com/watch?feature=player_embedded&v=r...

D is a language with operator overloading and function overloading (no keyword arguments however), at it compiles even faster than Go.

    /tmp/dmd2/src/phobos/std$ wc -l *.d | grep total
     162688 total
    /tmp/dmd2/src/phobos/std$ time dmd -c *.d > /dev/null
    std.cpuid has been deprecated. It will be removed in January 2013. Please use core.cpuid instead.
    std.md5 is scheduled for deprecation. Please use std.digest.md instead
    std.perf has been deprecated. It will be removed in January 2013. Please use std.datetime instead.
    Notice: As of Phobos 2.055, std.regexp has been deprecated. Please use std.regex instead.
    
    real	0m1.210s
    user	0m1.016s
    sys	0m0.188s
1.2 second to compile 162k LOC. Not too shabby!

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

#120
post #84

The programming language is called Go, NOT Google Go.

He only used it in the title... probably better as "Google's Go" or somesuch. I can see why he did it though. Go ironically has to be the least Googleable new language name since C++ (ok, until they changed the search syntax). It's the name of a popular board game, a less popular programming language (Go!), and an incredibly common verb.

What is wrong with "The Go Programming Language: The Good, the Bad, and the Meh"?
Post reply on HN