Are any Google projects currently using or evaluating Go for production?
From r60 to Go 1
21–30 of 30 posts
Re: From r60 to Go 1
#22Anyone using or planning on using Go in the near future? For what? It looks intriguing but I can't think of any obvious immediate applications (I'm sure there are plenty, I just don't see them).
I'm using it to build a world server for a multiplayer game. A lot of people suggest Scala/Java, Erlang, or Node.js for this, but I'm using Go. Go has a good, efficient memory model that lets me simulate a heck of a lot more of my world per megabyte of RAM. In today's world of hosting, that translates into a huge impact on how many dollars per user/hour we need to pay to run our game. That can have a direct translati…
Would love to hear more in the form of a blog post; perhaps when the world server has shipped.
+1 on memory usage. OOM is a killer for long running apps (pun intended)
Re: From r60 to Go 1
#23I am excited by golang and plan to start hacking with it. Here's why: 1. language designed with good intentions ( http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the... ) 2. designed and built by a group of veteran system researchers and engineers (ie. not javascript) 3. implementation open sourced from the start: http://code.google.com/p/go/source/browse 4. not overdesigned ( http://golang.org/doc/go_faq.ht…
> Its success, like most languages, will depend on library support.
By that measure Go's standard library is very extensive: http://weekly.golang.org/pkg/
There are also a lot of 3rd party packages (e.g., http://godashboard.appspot.com/package) most of which can be installed in a single command.
For my purposes, Go's standard library has proved as complete as Python's (http://docs.python.org/library/index.html) and includes some things that the Python standard library doesn't (e.g., crypto, graphics), all the more impressive IMO considering how relatively young Go is.
Re: From r60 to Go 1
#24What's wrong with makefiles and why is new Go convention better?
Horrible syntax.
Manual labor to write them that a build system could automate for you.
Not convenient enough for large projects, so people write makefile-making tools anyway.
It turns out a mess.
Re: From r60 to Go 1
#25Are any Google projects currently using or evaluating Go for production?
Yep, there are some Go services at Google that handle a staggering amount of traffic. I hope to be able to discuss one of the services publicly later this year. (Yeah, confidentiality is a drag.)
Re: From r60 to Go 1
#26Note that Go 1 hasn't been released yet, but can be previewed from the weekly tag.
Re: From r60 to Go 1
#27Anyone using or planning on using Go in the near future? For what? It looks intriguing but I can't think of any obvious immediate applications (I'm sure there are plenty, I just don't see them).
Used it experimentally to port a python tool that does some log aggregation with several options (read backwards, query on fields, etc) and returns the results in JSON.
A straight line by line port (ie less idiomatic Go) runs at about twice the speed of Python and with the same memory footprint. With the right fine tuning should be even better.
It was also very easy to do -- i.e code translated quite easily from Python to Go.
Re: From r60 to Go 1
#28Are any Google projects currently using or evaluating Go for production?
There is an experimental release of Go for Google's App Engine: http://code.google.com/appengine/docs/go/overview.html. It's mature enough that it was used in production to generate the Thanksgiving 2011 Google Doodle: http://blog.golang.org/2011/12/from-zero-to-go-launching-on-....
They Go App Engine team have also very recently pushed out beta releases that are tracking the weekly Go releases leading up the final Go 1 release, so I think it's safe to say that Go will be officially supported on App Engine not too long after Go 1 is released.
Re: From r60 to Go 1
#29Earlier quoted context omitted.
I actually thought that to start with but when you get used to the frankly wierd type system, it actually works extremely well without generics (bear in mind I use C# which is heavily generic programming). When you approach the problems with a Go mindset, I don't think I've found a single case that needed generic types. I'm not sure of the value of unions now or ever as it brings what is effectively a compiler decisi…
Discriminated unions are neither architecture-dependent nor unsafe.
A "tagged union" which is what I assume you mean is usually abstracted as a native type (struct) in other langauges (Go included). C gives you architecture level access to it. Go leaves it to the VM to decide.
Re: From r60 to Go 1
#30Anyone using or planning on using Go in the near future? For what? It looks intriguing but I can't think of any obvious immediate applications (I'm sure there are plenty, I just don't see them).
I'm using it to do http traffic analysis on captured packets... about 2.5 million packets a second at peak. This is to provide realtime charts for our web service which didn't have realtime reporting hooks.
I am also using it for HTTP request reconstruction and retransmission in real-time to enable live-data and full load testing of pre-production code.