4 ms·

> Ideal language has every function perfectly designed in the stdlib That way of thinking only makes sense if nothing ever changes. You even bring PHP as a go

> Ideal language has every function perfectly designed in the stdlib That way of thinking only makes sense if nothing ever changes. You even bring PHP as a good example here of how this fails fast. The world has changed greatly since 2003. The Python standard library carries three XML implementations and an outdated HTML parser irrelevant for the modern world. These libraries were state of the art when they were written, but it's the world around it that changed. Now one can make the argument: why was it not modernized and updated? The simple answer is that people started building code against this and now depend on it working this way. The only way would be to completely rewrite them with new APIs, remove stuff no longer needed but then you're effectively back to just using crates.io and the likes. Except it's worse now because the standard library is a monolith and does not compose.

hiptobecubic 5y ago
On the other hand, code using those libraries still works, whereas code trying today's favorite parser will not work after community moves on and stops maintaining it. I agree you don't want everything in the stdlib, but havinga stdlib way to achieve something is pretty valuable, even if it's not the best way and never was.
- mplanchard 5y ago
  Why would code dependent on third party libraries break? It’s not like crates.io is going to stop hosting them when they become unmaintained. Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years. In cases where libraries don’t keep up with changes in standards or whatever, yeah, you’re going to have to find another library. This is a part of our job that is pretty much unavoidable no matter the language. We should learn lessons like sticking dependencies you’re not certain about behind an interface to minimize the cost of switching if possible.
  - Macha 5y ago
    > Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years. JSON library updates are a constant tedious chore for many in the Java world. Jackson and Gson have both had several we've needed to make over the years. Now, _most_ of these are due to non-default features where you allow it to deserialize arbitrary types that we don't use. But clients big enough to insist on a BOM and internal security teams both just see "Jackson version x.y.z has a RCE on it, you need to update", even if it's literally impossible to trigger without changing the application code to enable insecure features.
    - mplanchard 5y ago
      You’re right, a json parser may have been a poor choice. Perhaps something like a UUID generator, or a parser for some more well-established and stable text format would be a better example. On the other hand, something like a json parser needing to change all the time to support the ecosystem is another good reason to keep it out of the stdlib, IMO. There are limited hands to work on Rust itself, and I’d rather they spend their time making improvements to the core of the language, stabilizing features, and so on. As a user of rust, I’m willing to pay the cost of finding a good json library if it means I don’t need to update rust versions just to deal with some issue in JSON parsing.
      - Macha 5y ago
        At the same time, code that is "one and done" like a uuid generator is a much lower maintenance burden for the standard library.
        mplanchard 5y ago
        Very true! I think the philosophy of letting external crates handle it and seeing how stable they are before considering inclusion in the stdlib is a good one here. Maybe in a few years we see that the uuid crate never needs updates and is super stable, so someone opens an RFC to pull it into std. The thing is it’s easy to be wrong if you’re trying to predict up front what is going to wind up being stable and low maintenance and what isn’t, so the precautionary nature of what gets into the stdlib I think reflects that.

hiptobecubic 5y ago

On the other hand, code using those libraries still works, whereas code trying today's favorite parser will not work after community moves on and stops maintaining it. I agree you don't want everything in the stdlib, but havinga stdlib way to achieve something is pretty valuable, even if it's not the best way and never was.

mplanchard 5y ago
Why would code dependent on third party libraries break? It’s not like crates.io is going to stop hosting them when they become unmaintained. Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years. In cases where libraries don’t keep up with changes in standards or whatever, yeah, you’re going to have to find another library. This is a part of our job that is pretty much unavoidable no matter the language. We should learn lessons like sticking dependencies you’re not certain about behind an interface to minimize the cost of switching if possible.
- Macha 5y ago
  > Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years. JSON library updates are a constant tedious chore for many in the Java world. Jackson and Gson have both had several we've needed to make over the years. Now, _most_ of these are due to non-default features where you allow it to deserialize arbitrary types that we don't use. But clients big enough to insist on a BOM and internal security teams both just see "Jackson version x.y.z has a RCE on it, you need to update", even if it's literally impossible to trigger without changing the application code to enable insecure features.
  - mplanchard 5y ago
    You’re right, a json parser may have been a poor choice. Perhaps something like a UUID generator, or a parser for some more well-established and stable text format would be a better example. On the other hand, something like a json parser needing to change all the time to support the ecosystem is another good reason to keep it out of the stdlib, IMO. There are limited hands to work on Rust itself, and I’d rather they spend their time making improvements to the core of the language, stabilizing features, and so on. As a user of rust, I’m willing to pay the cost of finding a good json library if it means I don’t need to update rust versions just to deal with some issue in JSON parsing.
    - Macha 5y ago
      At the same time, code that is "one and done" like a uuid generator is a much lower maintenance burden for the standard library.
      - mplanchard 5y ago
        Very true! I think the philosophy of letting external crates handle it and seeing how stable they are before considering inclusion in the stdlib is a good one here. Maybe in a few years we see that the uuid crate never needs updates and is super stable, so someone opens an RFC to pull it into std. The thing is it’s easy to be wrong if you’re trying to predict up front what is going to wind up being stable and low maintenance and what isn’t, so the precautionary nature of what gets into the stdlib I think reflects that.