TwinTechs

So, the folks at Google have been as busy as ever.  They just released a new language Go.  It has a loosely C-like syntax, compiles directly to native code, and is meant to be a low-level “systems” language.

I happened to be right in the middle of performance-tuning a FastCGI library in Python, with a focus on concurrent I/O problems.  This means I was also right in the middle of being frustrated with Python’s poor support for concurrency.

So, when I read about Go’s emphasis on concurrency without threads (a focus of my current efforts to use asyncore to avoid threads in Python), I couldn’t resist learning enough of the language to compare it’s network I/O performance with Python.

I wrote a quick Echo server (40 lines of code) this morning, and was impressed at how quickly it was going.   Then I looked at the executable, 850kB!  Ok, so, we will have to forgive them for having some unoptimized build tools for now.  At this point I was already not excited about the potential for getting a meaningful performance comparison, but I was still interested to learn more so I decided to get more coffee, and go ahead and do a quick and dirty implementation of FastCGI.

The server works by running one master loop that accepts connections, creates new “goroutines” to handle each connection, and since in FastCGI each connection can potentially multiplex requests over one connection, each of these handlers spawns a “goroutine” for each request.  I’m pretty sure that I am using a couple too many, or too few, channels, but it’s a working library in one day.

For a language that is not intended to be about coding productivity, I am quite impressed at how quickly I was able to do the things I needed.  The documentation is decent, and every documentation page links directly into the source code, so it encourages reading the source, which can be very helpful with something this young.

So far, I would describe the language as immature, but promising.  Other people have complained about the lack of generics, but for a “systems” language, I can understand why they aren’t a priority.

My biggest problem  is that their asynchronous implementation of network I/O is incomplete.  While all the main socket system calls like Read, Write, Listen, Connect, etc. are internally made safe for use by “goroutines”, the Close() system call exposes a race condition when one “goroutine” is creating sockets, and another is closing them.  Hopefully, this is just a growing pain that will be ironed out soon.

For now, my Go implementation doesn’t come close to my Python library (the Go is about 40% the speed of the Python)… but it’s nothing close to a fair fight yet.