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.)
[0]: https://github.com/openssl/openssl/commit/70428eada9bc4cf314...
[1]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...
[2]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...
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 [3].
[3]: https://moxie.org/blog/the-cryptographic-doom-principle/
EDIT: Interestingly, this was found with TLS-attacker [4], 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.
[4]: https://github.com/RUB-NDS/TLS-Attacker
IMPACT [EDIT]: to sum up, if a client uses AES-CBC to connect to a server with AES-NI support, a MitM can recover at least 16 bytes of anything it can get the client to send repeatedly, together with attacker-controlled data (think Cookies or such, using Javascript cross-origin requests).