Ended up watching it, and at the end they said that doozer solves a problem that they don't currently have. He really didn't go into why. Maybe because it was a heroku project he didn't want to talk bad about it? No idea.
Well, given that YouTube is one of Google's most resource-intensive sites (remember that acquisition back in 2006?), I'd say that alone makes them a pretty heavy user; plus, that's just the bit they've open-sourced. The Go team makes constant reference to assorted internal infrastructure projects for which Google uses Go, but which have not been and which probably never will be publicized.
youtube is part of google, and apparently all mysql requests at youtube now go through vitess (or so I read). That strikes me as pretty heavy use.
I recall reading somewhere that Go was used for some other internal projects, but never heard what exactly for. So maybe it was just someone talking about some greenfield "20% time" projects or something.
I've been using Go for a few months on a few different projects. Neither are my "day job".
The first project is a Google Music player app for Chumby devices (and other similar ARMv5/v6 class devices... will probably port to Raspberry Pi if/when I ever get one). The project is pure Go at this point with its own UI toolkit based on an mmaped /dev/fb.
The second project is a web service API for mobile apps plus an associated webserver.
I hope more companies adopt Go, making it a viable language for commercial programming. Using it is the most fun I've had coding in years.
We are using it at Janrain [ http://janrain.com ] for a web-hook/callback system. It will go into production over the next few weeks and is an important feature which will need to deal with a heavy load.
It has worked out great so far. Might write about our experiences once it has a few miles on it.
We (a group at the Institute for Systems Biology) use it for some cluster management software (http://code.google.com/p/golem/) that coordinates 10's of thousands of core hours most days. The consistency and compactness and fast compilation of the language make it a joy to work in and the concurrency features and packages for basic http and web sockets etc make it great for wiring up distributed infrastructure. The standard go packages for http are so much better then the python ones it isn't even funny.
We leave our processes running for months and memory usage stays quite low and stability good which is surprising considering the minimal time spent in development (note: we run on 64 bit linux). (Actually the other day I realized we had generated 24 gb log file because no one had restarted the master process in months.)
We still use other languages for linear algebra heavy things or things that benefit from a more complete webframework (in terms of both features and documentation) but I am hoping the go ecosystem develops in those areas.
We are using Go at Torbit. We can write high level code and still get C-like performance. It gives us the rapid development of an interpreted language, with the stability and performance of a compiled language.
There's a difference between an X programmer and a developer with programming experience in language X. The former is either incapable, unwilling or not expected to program in anything other than X. The latter has no implied limitations.
In the specific case where X is Go, requiring previous experience is a signal that the company might not be hiring skilled developers. Skilled developers can learn Go quickly because of the language's small size and consistency.
You're right. Most of our guys are using Go for the first time. What I should have said is we use Go at Torbit and we're hiring. If you want to program in Go and work on technology that touches millions of people every day, come join us!
I'm using Go with Google AppEngine. Seems to be about an order of magnitude less resource intensive than the Python versions of the apps. Not exactly surprising, considering that Google developed the language. And of course the team has leveraged the learnings from C / Unix and Inferno.
Don't forget that the Go suite contains C compiler and assembler as well for multiple platforms. In the Inferno version it was very easy to do cross-platform compilations.
I have just started playing with it primarily to rewrite chatfor.us as I want to see if I can build the full stack without extra dependencies. Chatfor.us uses zeromq and tornado along with virtualenv so I am hoping with go I can speed up development as well as take better advantage of multi core systems with less dependence on load balancing.
I was already planning on rewriting the authentication to work with more than just twitter so it seemed like a good time to try rewriting it in go. Also go is supposed to have a really nice mongodb db interface so I wanted to give that a try as well.
I am a systems engineer, I worked a lot in filesystems and filesystem-like things. About one year ago I started using Go instead of C for new projects, with the exception of kernel programming where the existing environments are too different for Go to integrate well. I'm very happy, I don't want to go back.
I am seriously considering Go for a portion of a desktop application. This portion needs to be cross-platform (Linux, OS X, and Windows), thread-aware, and safe (I really don't want buffer overruns raining on my parade).
I would also prefer to have a single executable as opposed to a run time that has to be installed first, especially since I want to be able to sign the executable.
Are there any other options out there that fits the bill? I don't consider C or C++ safe. Python, ruby and others are safe, but they aren't wrapped up as conveniently (especially on Windows). C# would work on Windows, but is less than ideal on OS X and Linux (but it is a contender, thanks to Mono).
I cant find the exact link to what I'm thinking of (I'll pop back if I do) but there are tools that package ruby scripts up with the runtime into one executable, especially on windows. There was one that could produce executables for many platforms, in the meantime take a look at https://www.ruby-toolbox.com/categories/packaging_to_executa...
The bad parts of Go are mostly the tradeoffs you have to make for a systems programming language. They have benefits but also some unfortunate downsides. Some are just implementation details that will get solved over time.
* integers overflow
* sharing memory between threads isn't safe
* mutable state/ shared state
* nil pointers
* block scoping can lead to multiple different variables with the same names within a function. Sometimes confusing.
* Error handling can become quite verbose if you don't design your code to limit the places errors can come from.
* gofmt is awesome, but in some rare situations the default format makes code less clear, so you have to change your style of code to fit the formatting.
* 'go get' is awesome, but it's lack of centralisation makes it harder to find the good 3rd party libraries amongst the bad/incomplete ones.
* The current goroutine scheduler is really simple and moves goroutines between threads and CPUs. This leads to lots of cache misses, so running on many threads can become slower than running on a single thread.
We were using it also for our web page (a custom blog engine made on go), but, we left it on alpha, and Go 1 changed a lot, gofix didn't fixed and priorities made us choose another tool for our web page.
Still, i think go only needs a desktop GUI toolkit to become popular. It has a lot of potential.
Docs Detective is using Go for its main document comparison algorithm. Its running on App Engine, where most of the app is in Java. Cross-language communication is done via the shared datastore and web-hooks.
I also use Go. Roughly 80% of the code I write is still Python (Django apps), but there are times when Go just makes the most sense... so that's what I use.
Whenever speed is key, I use Go. Its concurrency primitives are dead simple. It has excellent support for cutting-edge technologies like WebSockets and SPDY (these libraries/"packages" were written by Google), as well as MongoDB (see "mgo").
I'm using Go in production (for an almost-complete MVP). For a telephony app I had to dial 100 simultaneous phone numbers to bring people into conference calls. Trying that in Python maxed out my EC2 instance's resources. I had to kill and restart it from the AWS web interface.
Then I rewrote that part in Go. I was staring at the output of htop (similar to top) when it ran and thought something was wrong; it used a few megs of RAM, no noticeable CPU, and finished in 0.59 seconds _on a micro instance_. Now you can see why Google wanted such a language!
I never appreciated static typing ("who wants to go from Python to Java or C++?") until Go, which makes very heavy use of type inferencing. The upshot is you'll find yourself declaring types 0 times instead of twice in Java. In Python and Ruby you don't declare them at all, resulting in type errors _all over the place_ and programs that run ~20 times slower; see http://shootout.alioth.debian.org/u64q/benchmark.php?test=al....
The Go compiler tells me which lines contain the type errors. Usually my program is correct once these errors are gone. Can't say the same for Python, whose apps can run for days before a corner case is hit, exposing a type error that would've been caught at compile time in Go.
It's interesting that you mentioned Clojure. Well, it's powerful alright, but I found it to be extremely complicated (does a language _really_ need 4 kinds of concurrency and to consist of literally 500 functions?)
If you believe as I do -- as do most who appreciate small, simple, but extremely powerful languages like Python and C -- that simplicity is a feature, you will love Go. If you love Java, C++, D, and other huge languages, consider those or something like Scala or Clojure instead. IMO, doing so means giving up clarity/comprehensibility for a longer list of features, almost all of which _can_ be useful, but all of which make mastering the language much more difficult.
Go has been my favorite language for about a year now. Its only weakness is lack of library and/or framework support, which is an occasional bummer.
That said, I very strongly recommend giving Go a try if you haven't already. I played with Clojure for months till it finally made sense and I saw how powerful it _could_ be, but I still couldn't do anything with it that I couldn't do in Python.
After 2 hours with Go (1.5 years ago), I wrote my first ever concurrent program... _trivially_. This can not be stressed enough. Want a function call to `f` to be non-blocking? Type `go f()`. Yes, it's that simple. Launch a couple functions like that, and bam, you're doing extremely efficient concurrent programming.
If you want the convenience of Python or Ruby plus the speed and type safety of C++, give it a shot! http://golang.org
I am using it at CloudFlare for a backend application for optimizing HTTP connections. It consists of a server and client portion doing connection multiplexing, compression and a bunch of other low level stuff. The project has not been made public yet (but will be which I'll be able to talk about it more).
I could not have imagined writing this in Python or Ruby and I don't know Clojure at all.
Go was good because it's close to a systems language and has great concurrency mechanisms. The program makes extensive use of goroutines and channels for communication. I also make use of a large number of packages from the Go library as well as one external package for memcached integration.
So whenever people ask me about Go, I try and get them to keep in mind this isn't meant to be a competitor to python/ruby or any of that. Approach it from the mindset of a C guy and it will look amazing. The biggest benefits over python/ruby are static typing and that it is compiled. I know static typing isn't popular around here but it has its benefits. I love go and I know web programming is possible in it, but I'd never use it for that. To me it shines at system level services, embedded linux, and anything with high performances and reliability requirements without real time requirements.
We were actually having a talk today about using it here on an embedded Linux device we produce. I'm not very confident anything will come of it but I think it would be a good fit.
Indeed. There's been so much focus on interpreted langauges these days, compiled languages seem to be all but forgotten. C++ is the last new compiled language that's caught on. (There are others, like D, which are hanging in there, but don't seem to be gaining ground.) Go seems to have potential to grow into a successful compiled language.