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.
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...
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.
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.
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'.
"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.
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.
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..
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!
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.
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, 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.
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.