7 ms·
I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact
by strongly-typed 2y ago
I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug.
[0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd2c6f218091cc746150c05 https://github.com/semilin/genkey/commit/fafed6744555c5a81fd...
EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
- randomdata 2y ago> The fact that this was a bug at all makes me fear for the rest of the code base. The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.
- nasretdinov 2y agoIs the wrong code in the new part of the diff or in the old one? Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh