In other words, constant time programming, which by definition means that you have to behave normally even if your offsets go negative, is HARD. (And when you don't put comments ANYWHERE, it's even harder.)
For the record, there is nothing Go or Rust could have done here. The bug is caused by having to write code that runs in constant time, by employing masks and behaving in exactly the same way irrespective of the pad value. If you want to blame the design of something, blame Mac-then-Encrypt in TLS 1.0.
See also The Cryptographic Doom Principle .
EDIT: Interestingly, this was found with TLS-attacker , a new framework to analyze, test and attack TLS libraries. Finding it was probably "just" a matter of sending a plaintext made entirely of the same right byte value, and noticing that the MAC check passes when it should not. However, so far we didn't have any tool or testsuite (which I'm aware of) to perform this kind of checks.
What's interesting about crypto to me is the prospect that every common crypto flaw has second- and third- order variants that we will not find out about for many years, the same way we've barely now got a grip on the interaction between C integers and buffer counting.