We had about 3 or 4 guys full time. On my silly little i3 laptop, the whole codebase builds in 18 seconds - I suspect most of that is our C extensions.

C extensions because something you wanted wasn't in go? Are you using cgo to build?

Yeah, we actually have a few cgo packages. We have OpenSSL bindings (we need to use our hardware accelerated crypto, go's crypto/tls lib doesn't support that (yet)), a faster CRC thing, we needed monotonic clocks and couldn't wait for Go 1.3, etc.

We'll be releasing a bunch of these. Particularly the OpenSSL bindings, which even without hardware acceleration are faster than Go's TLS library, and despite Heartbleed, OpenSSL is not vulnerable to timing attacks like crypto/tls is.

Presumably, because they were doing it line by line, and the Python version used C extensions (for performance reasons).

I wonder how many lines of code they ended up with afterward, although admittedly lines of code is a pretty silly metric. I think it is useful in orders of magnitude when describing the size of a project, 100 lines, 1,000 lines, 10,000 lines, 100,000 lines all speak volumes about effort. So I guess what I'm wondering if you got about a roughly similar sized code base or significant change difference?

EDIT: fixed my calculations again.

Without tests but with our supporting libraries, our codebase was 36784 lines of Python. Those same lines became 41717 lines of Go.

Counting lines of code is hard.

Actually in this case, comparing two languages doing exactly the same thing, LOC is a relevant measure (its a crap measure of programmer productivity). It could show the expressiveness of a language. Also I am a believer that less lines of code = less likely to have bugs.

Less code in general means fewer bugs. However, there's definitely an inflection point where you're trying to cram too much functionality into too few lines of code, and so the code you're writing is a lot more complex than it really needs to be. This is where Go shines, is in discouraging overly complex single lines of code that don't actually save the programmer any time.

Sure, python has list comprehensions, but I can tell you how often I've seen hugely over-complicated one line list comprehensions that were impossible to understand unless you were absolutely sure what it was supposed to be doing before you read the code. I've refactored some of those in my lifetime just to make them more readable. That's not to say that most simple list comprehensions aren't totally fine.

So, just saying fewer lines of code makes for fewer bugs is not 100% accurate. I'd say, less /functionality/ leads to fewer bugs. But except in extreme circumstances (like writing a whole framework to do one small task), actual lines of code does not correlate to the number of bugs.