> In fact, most bugfixes are a potential breaking change, when people start > relying on the bug.
I'm ok with breaking changes to fix bugs -- especially security / correctness related bugs -- but this is not an example of that. Removing a footgun is admirable, but can be done without breaking existing users. Java's Date class has many footguns, but their solution was to create an entirely new package (java.time) which is much better designed. Nobody gets API design right the first time. But if people are relying on the old API, and it isn't clearly a security / correctness bug, just leave it there and create a new API. In Nim, that could be a new module, or new functions in an existing module. No need to break perfectly-functioning code. > shooting for 0 or near 0 breaking changes means you compromise ability to > improve the language for all future users for the benefit of the few existing > users that are unwilling to accommodate those breaking changes Breaking changes punish your _most enthusiastic_ users. It's easy to fix breakages in a small hobby project. For 10,000+ line projects, even superficial breakages can be very labor-intensive to fix. You're punishing the people who invested the most in the language. Does it make sense to force folks like Status or Beamdog, who have large Nim codebases, to "accommodate" breaking changes, for the sake of hypothetical future users? I suspect those future users will not exist, because no language has become popular while constantly breaking the contract it has with its existing users. > and then you end up with C++ where you have to live forever with early bad > decisions. Languages like C++ and Java are pervasive in part _because_ of their commitment to backwards compatibility. Constantly punishing those who invested in Nim is a great way to ensure that it never reaches escape velocity.
