Google Go: Good For What?(lessonsoffailure.com)
lessonsoffailure.com
Google Go: Good For What?
http://www.lessonsoffailure.com/software/google-go-good-for-nothing/
11 comments
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
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
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...
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...
I haven't written any Go, but the FAQ (http://golang.org/doc/go_faq.html#principles) says:
"There are no forward declarations and no header files; everything is declared exactly once."
Is the author just wrong, or has the language changed since the FAQ was last updated?
"There are no forward declarations and no header files; everything is declared exactly once."
Is the author just wrong, or has the language changed since the FAQ was last updated?
He confuses forward declarations with "declaring the type before the variable name".
I think you mean "declaring the variable name before the type".
So C is "int x" where Go is "x int". BASIC is typically more like "DIM x AS INTEGER".
So C is "int x" where Go is "x int". BASIC is typically more like "DIM x AS INTEGER".
For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax. But the designers make a very compelling case for why it's the right syntax: C function pointers are needlessly convoluted.
Scala is the same way, and their rational is that it makes it easy (in the parser, I guess) to just omit the type.
It is weird at first, but you get used to it, like everything syntactic.
It is weird at first, but you get used to it, like everything syntactic.
>For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax.
Why hate something trivial that takes 2 minutes to adjust to and has benefits without any drawbacks whatsoever?
Why hate something trivial that takes 2 minutes to adjust to and has benefits without any drawbacks whatsoever?
Doesn't hating something usually imply that one is being irrational about it?
I'm sure `tptacek` will get over it :-)
I'm sure `tptacek` will get over it :-)
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.
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.
Go also isn't described as a systems language anymore, but rather as a general-purpose language, although this article predates that change.
It's worth noting that this post is from December 2009.
This is often the most important thing about an article and often overlooked. Second scruffy http://www.youtube.com/watch?v=ggRLVdOoNGI
Exactly.
"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.
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.
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.
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.
A gross and incorrect generalization. It should have been:
Go: Good here, bad there.
Go: Good here, bad there.
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.
People interested in generating more optimized machine code (more slowly) should check out gccgo, which is a GCC frontend for Go, rather than the default (fast) gc compiler suite.
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.
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..
It's not the plan; they already exist: gc is the default, fast suite of compilers; gccgo is a Go front-end for GCC.
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??
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!
It's worth reading http://commandcenter.blogspot.com/2012/06/less-is-exponentia... 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.
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.
> 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.
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.
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.
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.
Also, I would say that Whitespace being "simpler" than Python is a fallacy, or at a minimum a reductive reading of the word "simple." I doubt the rules for writing in ASM, C, or whitespace are all that simple, despite the building blocks being relatively simple or few.
Honestly, I'm just repeating variations on http://www.infoq.com/presentations/Simple-Made-Easy.
Honestly, I'm just repeating variations on http://www.infoq.com/presentations/Simple-Made-Easy.
Go does not require a JVM.
What isn't in Scala? It seems to include everything but the kitchen sink. I would prefer to read/debug Go code over Scala and that makes all the difference to me. Go is a simpler language. It seems you need a PhD to fully appreciate Scala.
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.