Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to, but once you corrupt the map data structure, weird things can happen. Trying to contain that explosion isn't necessarily "better", as it would make maps slower / take up more memory / etc.
> Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to
The reasons C compilers “tend to go out of their way to make weird things happen” is they optimise extremely aggressively, and optimisations are predicated upon the code being valid (not having UBs).
Go barely optimises at all, and does not have that many UBs which could send the optimiser in a frenzy.
