The most surprising-looking thing here is the really wretched results from the Go version. But when you actually take a look at the Go code, that stops being so

The most surprising-looking thing here is the really wretched results from the Go version. But when you actually take a look at the Go code, that stops being so surprising; he's using a CSV-reading library whose author clearly wasn't thinking much about performance. It doesn't contain anything really super-dreadful -- O(n^2) algorithms for processing strings, etc. -- but it's full of gratuitous constant-factor inefficiencies compared with what you'd be likely to do in, say, C. Unnecessary temporary objects (presumably allocated on the GCed heap), building short strings by { read a byte, push it into a string-builder, repeat }, etc. It's the kind of code is makes sense to write in a higher-level language where (1) allocation overhead is likely to be swamped by interpretation overhead and (2) you know that for anything that really needs to be fast you'll punt to an extension library written in C. But Go is not such a language, even though it tries to offer some of the same conveniences as they do.