4 ms·

>> "the standard library is where code goes to die" I disagree. It's more like the code has ascended (https://nethackwiki.com/wiki/Ascension https://nethackwi

>> "the standard library is where code goes to die" I disagree. It's more like the code has ascended (https://nethackwiki.com/wiki/Ascension https://nethackwiki.com/wiki/Ascension). It has won because it is useful enough and mature enough to accompany the language and serve everywhere. Depending on what it does, standard library code may be used everywhere. For example, would you say that the Rust's Vec (https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html) is "dead"? It can still get new features added. It will still get bug fixes. But its primary APIs are engraved in stone, never to change because it would break all the code that depends on it. Granted, some code that goes into standard libraries will eventually fall out of use, or will be replaced by something better. In such cases, the code should be marked deprecated and eventually removed in a future edition of the language. In that case, it is like the code retires or could even be forked into a community-supported library in case it does still need to be used.

JonChesterfield 3y ago
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.

JonChesterfield 3y ago

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.