It's very interesting to see stories about Google Go, although I wish this one had gone into a little more technical detail with perhaps an example of something interesting that's been done with go routines and channels. I'm very drawn to Google Go because of my background in CSP and as an old-school C programmer. My experience with it has been very positive.
Go has really been great fit for web based APIs where I work. Going from multiple servers running PHP-FCGI to a single server running a Go app behind Nginx has reduced costs significantly.
"In our tests, Go's performance blew away most of the competition."
Since it didn't blow away "all" of the competition, this reader is curious about which other stacks held their ground.
This reader is also curious as to why Erlang wasn't in the competition, since Erlang meets all of the stated requirements (same programming language for backend and frontend systems, fast HTML templating system, fast start-up, modular recompilation, lots of connections on one machine, language tools for handling application-level concurrency, good performance, robust RPC layer to talk between tiers, lots of libraries, and open source). I'm guessing there was an unstated requirement along the lines of "syntax is not weird".
It's not only syntax, I think Erlang although a very good language, puts you in a different mode of thinking. This might be a good thing, but it also makes it harder to find developers to work on your project as they are less abundant.
I'm really interested in Go, but I wish they would elaborate on statements like this:
Although Go is a young language, it has a lot of system
packages and a growing number of user-contributed
packages. With only a few exceptions, we have found Go
packages for everything we have needed.
Highlighting what is missing is the best way to fill in the gaps (especially on a blog directed at eager developers like this)
You can see a few of the packages we wrote ourselves as we open sourced them: http://www.stathat.com/src
Basically what I was referring to as missing were the Amazon SES package and braintree. We haven't released the package for braintree yet, but we will.
I wonder if GO can be used as a new front-end language, i.e., replacing javascript. The fast compile times certainly would make it feasible to compile the code at runtime in the browser and then execute in a sandboxed environment.
He says it would be impractical for other browser vendors to keep up with the sprawling mess of APIs required by NaCl known as Pepper. Also Google's behavior around it's open source but not open standard tech like NaCl and Dart leaves a bad taste.
THAT was the question people kept asking Pike at conferences. and his answer to the question is "yes, we would like to see that happen too".
and i hope Google is listening. i mentioned in many comments before, i just see it there, unlike Dart.
i am not ignoring the hard work behind Dart or anything, but it's just my feeling that i wouldn't personally move from Javascript to something that just looks like Java. Javascript to Go or Python? definitely.
[+] [-] jgrahamc|14 years ago|reply
[+] [-] zerosanity|14 years ago|reply
[+] [-] EvanMiller|14 years ago|reply
Since it didn't blow away "all" of the competition, this reader is curious about which other stacks held their ground.
This reader is also curious as to why Erlang wasn't in the competition, since Erlang meets all of the stated requirements (same programming language for backend and frontend systems, fast HTML templating system, fast start-up, modular recompilation, lots of connections on one machine, language tools for handling application-level concurrency, good performance, robust RPC layer to talk between tiers, lots of libraries, and open source). I'm guessing there was an unstated requirement along the lines of "syntax is not weird".
[+] [-] patrickxb|14 years ago|reply
We'd love to experiment with Erlang at some point, at the very least to write an Erlang StatHat library.
[+] [-] langsamer|14 years ago|reply
[+] [-] thebigshane|14 years ago|reply
[+] [-] patrickxb|14 years ago|reply
Basically what I was referring to as missing were the Amazon SES package and braintree. We haven't released the package for braintree yet, but we will.
[+] [-] robfig|14 years ago|reply
The built-in RPC is nice, but it seems like one would still want to use something like Thrift -- I assume that non-Go servers cannot talk Go RPC
[+] [-] patrickxb|14 years ago|reply
[+] [-] enneff|14 years ago|reply
[+] [-] langsamer|14 years ago|reply
[+] [-] Detrus|14 years ago|reply
He says it would be impractical for other browser vendors to keep up with the sprawling mess of APIs required by NaCl known as Pepper. Also Google's behavior around it's open source but not open standard tech like NaCl and Dart leaves a bad taste.
[+] [-] nvictor|14 years ago|reply
and i hope Google is listening. i mentioned in many comments before, i just see it there, unlike Dart.
i am not ignoring the hard work behind Dart or anything, but it's just my feeling that i wouldn't personally move from Javascript to something that just looks like Java. Javascript to Go or Python? definitely.
[+] [-] hurrycane|14 years ago|reply
PS: I presume the graph drawing library is written in-house, what did you use as the building blocks for it (both for design and implementation) ?
[+] [-] patrickxb|14 years ago|reply
And, yes, the chart drawing library was written by us. It uses cairo for drawing primitives.
[+] [-] langsamer|14 years ago|reply
I wanted to use the experimental support for GO in google app engine but it seems fairly limited...at least for the time being.
[+] [-] BarkMore|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]