4 ms·

The eventual removal part doesn't tend to happen. Changing the API to a better one breaks people so that's out too. Adding more stuff to the interface is ok in

The eventual removal part doesn't tend to happen. Changing the API to a better one breaks people so that's out too. Adding more stuff to the interface is ok in terms of things continuing to work and over time makes the library rather large. If the new interface is better there's a good chance it's different and thus inconsistent with the previous code. Bug fixes are tricky too. If they're semantically observable people probably depend on the current behaviour. Languages vary in how well they handle this. Python and C++ are the usual mistakes are forever example. Perhaps rust or c# have a better strategy. Training users to act on deprecation warnings and ensuring they actually have an alternative would be a good play. Lua manages to break things a bit over time. Python tried it once and will forever fear the flame. C++ refuses to recompile anything and fears the word ABI.

ptx 3y ago
> The eventual removal part doesn't tend to happen. It's happening in Python 3.13: https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
thesuperbigfrog 3y ago
>> Bug fixes are tricky too. If they're semantically observable people probably depend on the current behaviour. Hyrum's Law (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/) definitely does come into play, but bugs do need to be fixed. Good communication is essential so that library users can adapt. In extreme cases, jarring fixes can turn into new APIs. >> Languages vary in how well they handle this. Python and C++ are the usual mistakes are forever example. Perhaps rust or c# have a better strategy. Rust's Editions (https://doc.rust-lang.org/edition-guide/editions/ https://doc.rust-lang.org/edition-guide/editions/) offer a nice way to gently break backward compatibility in order to keep everything progressing.
estebank 3y ago
> The eventual removal part doesn't tend to happen. For Rust it can't happen, because of the backwards compatibility guarantees: you can mark an API as deprecated, and potentially make those unavailable in later editions, but code that compiled on 1.0 (2015 edition) should continue to compile in perpetuity, so the API has to stay around in the stdlib so that older code still works (we dont have an stdlib per edition, it wasn't even originally envisioned to have editions affect the stdlib, only syntax and semantics). It shouldn't be a problem, but it is an inconvenient burden.

ptx 3y ago

> The eventual removal part doesn't tend to happen. It's happening in Python 3.13: https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/

thesuperbigfrog 3y ago

>> Bug fixes are tricky too. If they're semantically observable people probably depend on the current behaviour. Hyrum's Law (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/) definitely does come into play, but bugs do need to be fixed. Good communication is essential so that library users can adapt. In extreme cases, jarring fixes can turn into new APIs. >> Languages vary in how well they handle this. Python and C++ are the usual mistakes are forever example. Perhaps rust or c# have a better strategy. Rust's Editions (https://doc.rust-lang.org/edition-guide/editions/ https://doc.rust-lang.org/edition-guide/editions/) offer a nice way to gently break backward compatibility in order to keep everything progressing.

estebank 3y ago

> The eventual removal part doesn't tend to happen. For Rust it can't happen, because of the backwards compatibility guarantees: you can mark an API as deprecated, and potentially make those unavailable in later editions, but code that compiled on 1.0 (2015 edition) should continue to compile in perpetuity, so the API has to stay around in the stdlib so that older code still works (we dont have an stdlib per edition, it wasn't even originally envisioned to have editions affect the stdlib, only syntax and semantics). It shouldn't be a problem, but it is an inconvenient burden.