4 ms·

I think it's clear to me that Rust needs to start admitting more into the STD to help with this and increase the consistency across the ecosystem.

vacuity 1y ago
No, I think the idea of blessing a set of crates (with versions!) is better. The stdlib has a high burden of maintenance, and ideally should only be added to if changes are always backwards compatible. A blessed set is more flexible but still provides a high degree of reliability, unlike the present situation.
- steveklabnik 1y ago
  This has been tried a few times, and in practice, people prefer the current status quo.
  - vacuity 1y ago
    I'm not aware of the attempts, but at least the route of adding more to the stdlib seems even worse, although it may be popular.
    - steveklabnik 1y ago
      Oh yeah, I would agree with that for sure.
Ygg2 1y ago
This has happened already. See https://doc.rust-lang.org/std/cell/struct.LazyCell.html https://doc.rust-lang.org/std/cell/struct.LazyCell.html It's just it's not frequent. There is very few things that need to be in the standard library. I only ever miss chrono or equivalent not being in std.
- nixpulvis 1y ago
  Time functions are a prefect example of somewhere there should be expanded support for in the STD. I'm also of the opinion that there should be a generic and reasonable async runtime in STD, since having `async` in the language, but to direct way to use it without a crate or writing your own executor is awkward. Then there are things like serialization and logging, which I like the idea of having promoted crates which are essentially just better advertised for newcomers. (Maybe included in the distribution already in some way).
- burntsushi 1y ago
  If Chrono were in std, that would have been a disaster IMO.
  - Ygg2 1y ago
    Not exactly chrono crate (to quote "chrono or equivalent"). More like Java's version of chrono.
    - burntsushi 1y ago
      But what if we did that 5 years ago? Oops. And even Java's API has problems too. Why not let it be provide by the ecosystem where it can qctually evolve?
      - Ygg2 1y ago
        What problems does Java JSR 310 have (old Java time yes, but those are known issues)? As far as I have used it, it was damn near perfect.
        burntsushi 1y ago
        It lacks a hybrid duration type. Instead, it splits durations into calendar and time durations and conflates the length of a `day` depending on whether it's in `Period` or `Duration`. And AFAIK, it doesn't support time zone aware duration rounding. And I don't see a way to compute a `Period` from two `ZonedDateTime` values in a way that respects time zone transitions. To be clear, it's good. But there are mistakes that the Temporal project learned from and fixed. (Temporal's single `Duration` type does have pros and cons, so I don't mean to frame having two distinct types as a strict negative. But it's very clunky.)

vacuity 1y ago

No, I think the idea of blessing a set of crates (with versions!) is better. The stdlib has a high burden of maintenance, and ideally should only be added to if changes are always backwards compatible. A blessed set is more flexible but still provides a high degree of reliability, unlike the present situation.

steveklabnik 1y ago
This has been tried a few times, and in practice, people prefer the current status quo.
- vacuity 1y ago
  I'm not aware of the attempts, but at least the route of adding more to the stdlib seems even worse, although it may be popular.
  - steveklabnik 1y ago
    Oh yeah, I would agree with that for sure.

Ygg2 1y ago

This has happened already. See https://doc.rust-lang.org/std/cell/struct.LazyCell.html https://doc.rust-lang.org/std/cell/struct.LazyCell.html It's just it's not frequent. There is very few things that need to be in the standard library. I only ever miss chrono or equivalent not being in std.

nixpulvis 1y ago
Time functions are a prefect example of somewhere there should be expanded support for in the STD. I'm also of the opinion that there should be a generic and reasonable async runtime in STD, since having `async` in the language, but to direct way to use it without a crate or writing your own executor is awkward. Then there are things like serialization and logging, which I like the idea of having promoted crates which are essentially just better advertised for newcomers. (Maybe included in the distribution already in some way).
burntsushi 1y ago
If Chrono were in std, that would have been a disaster IMO.
- Ygg2 1y ago
  Not exactly chrono crate (to quote "chrono or equivalent"). More like Java's version of chrono.
  - burntsushi 1y ago
    But what if we did that 5 years ago? Oops. And even Java's API has problems too. Why not let it be provide by the ecosystem where it can qctually evolve?
    - Ygg2 1y ago
      What problems does Java JSR 310 have (old Java time yes, but those are known issues)? As far as I have used it, it was damn near perfect.
      - burntsushi 1y ago
        It lacks a hybrid duration type. Instead, it splits durations into calendar and time durations and conflates the length of a `day` depending on whether it's in `Period` or `Duration`. And AFAIK, it doesn't support time zone aware duration rounding. And I don't see a way to compute a `Period` from two `ZonedDateTime` values in a way that respects time zone transitions. To be clear, it's good. But there are mistakes that the Temporal project learned from and fixed. (Temporal's single `Duration` type does have pros and cons, so I don't mean to frame having two distinct types as a strict negative. But it's very clunky.)