1. 3
  1. 3

    I did python for several years, and this anecdote is accurate. It also reminds me of why I do my best to avoid python for things that might be performance sensitive. If you care about performance you end up crawling through the standard library looking for some function written in c that does some approximation of what you want because even a really poorly written c function will probably beat the pants out of anything you can write. Disclaimer: pypy was never an option for me.

    It almost feels like cheating, but the equivalent go code for their problem would have been.

    func byte2string(vals []byte) string {
        return string(vals)
    }
    

    A somewhat more fair example might be:

    func int2string(vals []int) {
      var buf bytes.Buffer
      for _, val := range vals {
        buf.WriteByte(byte(val))
      }
      return buf.String()
    }
    

    A production ready example might pool/size the bytes.Buffer appropriately, but performance of WriteByte won’t be quadratic it will likely be amortized constant time append, just like a python list. Just like python, go can start with a naive solution, but unlike python the naive go solution probably won’t have to be tweaked until much farther down the path, and doesn’t require searching the standard library for c functions that can be abused.