4 ms·

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

gpm 4y ago
I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs). While I think there are valid arguments in both directions for putting more things like this in std, I don't think "non-bug issues have been open for over a year" is one of them. The exact same is true of std.
- jupp0r 4y ago
  > the standard library needs to avoid breaking changes at nearly all costs IIRC in Rust this is a little bit looser than elsewhere (let's say in C++) as the ABI is not stable. This allows improvements that change the internal structure of structs but not the API. As a counter example, in C++11 there was a breaking change that introduced a size field to std::list, making size() O(1) instead of O(n), breaking linkage between older and newer versions of C++ binaries. In Rust there is no such guarantee so changes like that could be introduced anytime.
  - FullyFunctional 4y ago
    Yes but everything is versioned so it's not like this will break any existing applications unless the user/owner explicitly upgrades (but then they should be ready for breakages). The absence of versioning hell with Rust is one of the many things I love about Rust.
    - LtWorf 4y ago
      On the other hand it means you don't automatically get security fixes and have to manually set up CVE monitoring and rebuild your application every time a CVE appears. Of course if it appears in an old version the author won't bother to backport the fix so you will have to bump the dependency to the latest, doing all the API changes that you didn't want to do.
      - supportlocal4h 4y ago
        Are we still talking about Rust or have we moved on to general grumbling about life?
        LtWorf 4y ago
        Any language with an insufficient standard library and a need to import small modules in large numbers. rust is one of them.
- ChrisSD 4y ago
  Yeah, I'd emphasize that moving something to the standard library doesn't magically solve maintenance issues. In fact if the community can't even maintain something then that's a strong argument for it not to be moved somewhere that's much harder to contribute to, whose maintainers have a lot else on their plate and where any API mistakes are for forever.
hda2 4y ago
This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anything in Rust despite loving the language. My last hopes for Rust are now in gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem. If this doesn't happen, I'll just continue to use other languages or limit my dependencies to those with sane package management (usually this means libraries written in C) until something better pops up.
- usrusr 4y ago
  There was a time when it felt as if every piece of interesting java code out there also came in variation badge-engineered into its matching "spring-whatever". Perhaps there is some merit to that kind of business model?
- Dangsuckslol 4y ago
  - ptato 4y ago
    > "standard library" does not exist as a concept. What? "The Rust Standard Library": https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/
- bscphil 4y ago
  > gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem Has there been discussion about this here on HN or an article about it you can point me to? I'm very much interested in exactly the same thing.
- pizza234 4y ago
  This is a tricky subject. Rust being a low-level library, adding something means inherently choosing a preferred approach to a problem rather than another, which may be disagreeble. The consequence is that there would be still the sub-sub-dependencies problem, because the author of a crate may decide that the stdlib implementation is not appropriate for the use-case (Rust is low-level; low-level development is typically "pickier" than web development). I personally think that it's good not to have higher level APIs in the stdlib. My only exception to this is the exclusion of fast hashing, because this choice had side-effects beyond simple need for an API.
dncornholio 4y ago
A github with open issues that hasn't been updated for over a year doesn't say anything about the code or quality.
svnpenn 4y ago
Yeah. FFS, they don't even have a JSON parser in the standard library...
- mustache_kimono 4y ago
  As a Rust user, I have to say I think this is the right choice. Keep things out until they are practically dead/done. Rust covers a very large number of language use cases from C++ to Python. C++ doesn't have a std lib JSON parser either. And serde is fantastic!
- rat87 4y ago
  Generally rust prefers to keep things out of the standard library because it's hard to change/improve a standard library. They try to give enough useful stuff and then leave all the other stuff to easily downloadable packages.
  - ssokolow 4y ago
    More importantly, it means that version upgrades are decoupled. They don't have to download and install version 1 of an API for backwards compatibility if you're on version 2, and you don't have to download a new compiler version to upgrade a package as long as the package's maintainer is still willing to support the version you're on. (That latter one being the same as with support for new revisions of C or C++ in in GCC.)
orlp 4y ago
Hey, slotmap author here. Last year has been a bit rough and I didn't have a whole lot of free time and energy to work on projects at the same time. That said, I don't believe any of the open issues on slotmap are of immediate need of attention, they are mostly minor feature requests/incremental improvements. I do have a slotmap 2.0 in the planning that will include most of these improvements and allow further customization and control of the number of bits used for index/generation as well as what to do when the generation would wrap around (either leak that specific slot or allow a spurious reference with a (very) old key).
- lenkite 4y ago
  Thank you for creating slotmap. It helps for folks who don't want to dig into nitty-gritty laborious unsafe code themselves. I only expressed the wish that something fundamental like this was was designed and incorporated as part of Rust stdlib.

gpm 4y ago

I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs). While I think there are valid arguments in both directions for putting more things like this in std, I don't think "non-bug issues have been open for over a year" is one of them. The exact same is true of std.

jupp0r 4y ago
> the standard library needs to avoid breaking changes at nearly all costs IIRC in Rust this is a little bit looser than elsewhere (let's say in C++) as the ABI is not stable. This allows improvements that change the internal structure of structs but not the API. As a counter example, in C++11 there was a breaking change that introduced a size field to std::list, making size() O(1) instead of O(n), breaking linkage between older and newer versions of C++ binaries. In Rust there is no such guarantee so changes like that could be introduced anytime.
- FullyFunctional 4y ago
  Yes but everything is versioned so it's not like this will break any existing applications unless the user/owner explicitly upgrades (but then they should be ready for breakages). The absence of versioning hell with Rust is one of the many things I love about Rust.
  - LtWorf 4y ago
    On the other hand it means you don't automatically get security fixes and have to manually set up CVE monitoring and rebuild your application every time a CVE appears. Of course if it appears in an old version the author won't bother to backport the fix so you will have to bump the dependency to the latest, doing all the API changes that you didn't want to do.
    - supportlocal4h 4y ago
      Are we still talking about Rust or have we moved on to general grumbling about life?
      - LtWorf 4y ago
        Any language with an insufficient standard library and a need to import small modules in large numbers. rust is one of them.
ChrisSD 4y ago
Yeah, I'd emphasize that moving something to the standard library doesn't magically solve maintenance issues. In fact if the community can't even maintain something then that's a strong argument for it not to be moved somewhere that's much harder to contribute to, whose maintainers have a lot else on their plate and where any API mistakes are for forever.

hda2 4y ago

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anything in Rust despite loving the language. My last hopes for Rust are now in gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem. If this doesn't happen, I'll just continue to use other languages or limit my dependencies to those with sane package management (usually this means libraries written in C) until something better pops up.

usrusr 4y ago
There was a time when it felt as if every piece of interesting java code out there also came in variation badge-engineered into its matching "spring-whatever". Perhaps there is some merit to that kind of business model?
Dangsuckslol 4y ago
- ptato 4y ago
  > "standard library" does not exist as a concept. What? "The Rust Standard Library": https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/
bscphil 4y ago
> gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem Has there been discussion about this here on HN or an article about it you can point me to? I'm very much interested in exactly the same thing.
pizza234 4y ago
This is a tricky subject. Rust being a low-level library, adding something means inherently choosing a preferred approach to a problem rather than another, which may be disagreeble. The consequence is that there would be still the sub-sub-dependencies problem, because the author of a crate may decide that the stdlib implementation is not appropriate for the use-case (Rust is low-level; low-level development is typically "pickier" than web development). I personally think that it's good not to have higher level APIs in the stdlib. My only exception to this is the exclusion of fast hashing, because this choice had side-effects beyond simple need for an API.

dncornholio 4y ago

A github with open issues that hasn't been updated for over a year doesn't say anything about the code or quality.

svnpenn 4y ago

Yeah. FFS, they don't even have a JSON parser in the standard library...

mustache_kimono 4y ago
As a Rust user, I have to say I think this is the right choice. Keep things out until they are practically dead/done. Rust covers a very large number of language use cases from C++ to Python. C++ doesn't have a std lib JSON parser either. And serde is fantastic!
rat87 4y ago
Generally rust prefers to keep things out of the standard library because it's hard to change/improve a standard library. They try to give enough useful stuff and then leave all the other stuff to easily downloadable packages.
- ssokolow 4y ago
  More importantly, it means that version upgrades are decoupled. They don't have to download and install version 1 of an API for backwards compatibility if you're on version 2, and you don't have to download a new compiler version to upgrade a package as long as the package's maintainer is still willing to support the version you're on. (That latter one being the same as with support for new revisions of C or C++ in in GCC.)

orlp 4y ago

Hey, slotmap author here. Last year has been a bit rough and I didn't have a whole lot of free time and energy to work on projects at the same time. That said, I don't believe any of the open issues on slotmap are of immediate need of attention, they are mostly minor feature requests/incremental improvements. I do have a slotmap 2.0 in the planning that will include most of these improvements and allow further customization and control of the number of bits used for index/generation as well as what to do when the generation would wrap around (either leak that specific slot or allow a spurious reference with a (very) old key).

lenkite 4y ago
Thank you for creating slotmap. It helps for folks who don't want to dig into nitty-gritty laborious unsafe code themselves. I only expressed the wish that something fundamental like this was was designed and incorporated as part of Rust stdlib.