About 13 years ago, I wrote my own programming language expressly for the purpose of implementing network stacks, and had a complete TCP in it; I didn't have this problem. But I do have this problem all the time when I write direct network code and forget about buffering.
Similarly: "Python is so slow that Google reset the network connection" seems a bit unlikely too. Google, and TCP in general, deals with slower, less reliable senders than you. :)
What's the time between your SYN and their SYN+ACK?
There's an iptables module called tarpit, which takes advantage of some peculiarities of the TCP protocol to essentially prevent the remote host from closing the connection, which can force (conforming?) TCP clients to take 12-24 minutes to timeout every connection. It can make portscanning unpleasantly expensive and time-consuming.
You can probably also come up with real-world applications for it (as a security tester, there are lots of applications for having full control over a TPC stack, regardless of how performant it is), but just having done it offers a huge learning return on a modest investment.
You probably don't fully grok what TCP even is until you've made congestion control work.
And sometimes you even want your stack to be slow, eg in a slow loris attack.
Being implemented around Twisted, it actually allows you to fiddle with low-level TCP stuff, while e.g. offloading the SSL to the existing stack. It saved my bacon a few times when I wanted to reproduce a complicated network breakage scenarios.
https://www.youtube.com/watch?v=BEAKtqiL0nM - Video about muXTCP from 22C3
https://github.com/enki/muXTCP - github repo with it.
Python: fast to write, slow to run.
C/C++: slow to write, fast to run.
To put it succinctly, you can write fast programs, and you can write programs fast, but you can't write fast programs fast.
Haskell, Clojure, and Ocaml do pretty well at writing fast programs fast for what I consider appealing values of fast.
I wouldn't be surprised if Google is sending the packets all at once and ignoring the ACKs altogether.
Heck, there's even a 2010 paper from Google on the subject of sending a bunch of packets at the beginning of the connection: An Argument for Increasing TCP's Initial Congestion Window
When you send ACKs, not only do you send the acknowledgement number indicating which byte you expect next, but you also send a window size indicating how many bytes you're willing to receive before the remote end has to wait for another acknowledgement. Normally you want this to be somewhat large so you don't spend lots of idle time waiting around for ACKs. (But not so large that packets get dropped). This is the key to TCP flow control, which was kinda glossed over in the blog post in the interest of keeping things simple.
But perhaps by default, you're advertising a too-large window considering the circumstances. I bet you could make this a lot more reliable just by advertising something smaller.
Good TCP implementations have overcome a lot more than some unwanted buffering.
Is your ACK sequence number the sum of all received data lengths? I think that is how that works?
So yes, if a C64 can handle it Python should have plenty of power.
Google's webservers, including the TCP stacks themselves, may be very aggressively tuned to make sure you get the response absolutely as fast as possible, at the expense of re-sending packets more quickly than specified.