

Google Go: Good For What? - neya
http://www.lessonsoffailure.com/software/google-go-good-for-nothing/

======
tptacek
From a previous Go blog post by the same author:

 _Go decided to use a foreign syntax to C++, C and Java programmers. They
borrows forward declarations from BASIC (yep, you heard me right…BASIC),
creating declarations that are backwards from what we’ve been using for close
to 20 years_

"Yep, you heard me right... BASIC". Consider carefully how seriously you want
to take this blog.

~~~
mseepgood
Go's declaration syntax has some benefits:
<http://blog.golang.org/2010/07/gos-declaration-syntax.html>

And they didn't borrow the declaration syntax from BASIC, but from Pascal:
<http://golang.org/doc/go_faq.html#ancestors>

At the time Pascal was invented BASIC distinguished variable types via name
postfixes like % and $.

Also, a "forward declaration" is not what the author seems to think:
<http://en.wikipedia.org/wiki/Forward_declaration>

~~~
snogglethorpe
What really annoys me about Go's declaration syntax is that they _left out the
colon_.

Like Pascal/Ada/etc, Go uses a postfix type declaration syntax, but the former
languages separate the variable from the type with a colon. This is both more
readable—the colon acts as a highly visible marker for the type, whereas with
the Go style, the variable and type end up sort of smudged together—and
because of its long history, much more familiar.

Go-style: var foo, bar int

Pascal-style: var foo, bar : int

My suspicion is that Go originally _did_ use a colon in declarations and they
got rid of it at some point for some reason, because Go's "auto-declaration"
syntax actually does use a colon, only without an explicit type: "x := expr"
makes much more sense if the normal declaration syntax is "x : type = expr"
("just leave out the type and it will be deduced")....

There doesn't seem any particularly good _reason_ to omit the colon, it's
neither onerous to use nor particularly space-consuming. Neither is it likely
it simply didn't occur to them, as the declaration syntax is probably
consciously based on that of Pascal-family languages. Given that it seem to
yield obvious benefits without any obvious problems, I'm mystified as to why
it was omitted.

Unfortunately for all its obvious goodness in some areas Go also seems to have
a number of these "WTF were they thinking" areas as well. The impression it
leaves is of a rough draft, not something polished. Sadly, these quirks are
pretty much set in stone now...

------
wglb
Ok, I will do this one more time.

The authors of go come from my generation. Back in those days, the term
"Systems Programming" meant something different than what wikipedia, and
probably most everyone today thinks of it.

Systems Programming in those days meant writing compilers, text processors,
unix command line programs. It did not then mean programming an operating
system, or anything near hard real-time.

Not a very high quality article.

~~~
thirsteh
Go also isn't described as a systems language anymore, but rather as a
general-purpose language, although this article predates that change.

------
hevyw8
It's worth noting that this post is from December 2009.

~~~
nicolas42
This is often the most important thing about an article and often overlooked.
Second _scruffy_ <http://www.youtube.com/watch?v=ggRLVdOoNGI>

------
JadeNB
Did the author change the title? It now reads "Google Go: Good for what?",
although the article (or, for that matter, the link) still quite clearly
suggests (and explicitly says at the end) that the answer is 'nothing'.

~~~
thirsteh
The conclusion is that "Go is good for absolutely nothing."

------
thirsteh
Somebody criticizing a language he freely admits to never having used.

Nothing interesting to see here.

~~~
slurgfest
By that token, there is nothing interesting to see in most of the language
advocacy posts on HN.

~~~
zellyn
Yes.

------
klrr
"I’d say there are plenty of non-starters to keep Go out of the application
programming space."

God, I've got tired of all desktop applications written in python, they're soo
slow. I hope Go gets used both in the application space and system space, so
not just our systems are fast, the applications too.

------
jasonmoo
Go is a young language with a growing community that should only get better as
more minds come to it.

For me it's very accessible for rapidly developing heavy-lifting tools, in
particular networking tools. It's not the only language but it's served me
well when I've reached for it.

------
sidcool
A gross and incorrect generalization. It should have been:

Go: Good here, bad there.

------
melling
How good is the Go optimizer? I would guess that there's still a lot of room
for improvement because that's not something you'd spend a lot of time on
early in the life of a language.

~~~
theatrus2
Basically, not much (depending on which compiler chain you are using). The
Plan9 based compilers (which compile at light speed) don't produce great code.

~~~
aaronblohowiak
They don't produce great code because they are optimized for compilation
speed. IIRC, the plan is to have your quick to compile compiler and your fast
execution time compiler..

~~~
thirsteh
It's not the plan; they already exist: gc is the default, fast suite of
compilers; gccgo is a Go front-end for GCC.

~~~
aaronblohowiak
I should have been clear: it is the plan to maintain this dichotomy

~~~
thirsteh
Yes.

------
davidpayne11
I'm genuinely curious - Scala is faster and better performant, what is there
in GO that there isn't in Scala? I mean, if you were to build a highly
scalable web app, why would you choose one over the other? Any thoughts??

~~~
430gj9j
Ask what isn't in Go that is in Scala. The Go authors deliberately left out
certain features to focus on what they call "clarity of design". I don't see
them ever adding XML literals for instance!

~~~
wonderzombie
It's worth reading [http://commandcenter.blogspot.com/2012/06/less-is-
exponentia...](http://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html) to get some idea of the motivation behind including
less.

If you believe that our software systems are increasingly complex _and_ that
some aspect of the problems we're solving are essentially complex, then the
strongest path towards simplicity lies in minimizing complexity incidental to
the problems we're solving. One facet of programming which routinely
introduces complexity is our tools, particularly our programming languages.

I believe both Rob Pike (and the Go authors) and Rich Hickey are both
motivated in part by this impulse or a variation on it. They chose very
different ways of addressing the problem, but Clojure and Go are a lot more
similar than you'd think.

~~~
chc
> _If you believe that our software systems are increasingly complex and that
> some aspect of the problems we're solving are essentially complex, then the
> strongest path towards simplicity lies in minimizing complexity incidental
> to the problems we're solving. One facet of programming which routinely
> introduces complexity is our tools, particularly our programming languages._

That is true, but I'm not sure the correlation you seem to be suggesting here
— that complex tools breed complex programs — is realistic.

A lot of the time, complexity can either live in your tools or in your
program. For example, garbage collection requires a more complicated toolset
than manual memory management, but in return it removes the complexity of
memory management from your code. Similarly, ASM is simpler than C, and
Whitespace is simpler than Python, but most people will agree that a program
written in the latter tends to be simpler than the same program written in the
former.

~~~
wonderzombie
GC is an abstraction which, although complex in implementation, is something
which makes your program simpler. So the correlation has less to do with _how_
our tools are implemented, but the properties of the tools as we interact with
them.

Also, simplicity, like security, is a trade-off. When performance is
paramount, people will reach for C or assembly, and rightly so. Conversely if
performance is not the #1 priority, developers feel free to use higher-level
languages like Java or Ruby.

