5 ms·

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't

• lenkite 4y ago
  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.
    • 4y ago
  • 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.
• fulafel 4y ago
  What is the advantage of a slotmap style approach vs references? It seems a bit manual and error prone, and the errors risk being silent references to wrong objects that may result in security vulnerabilities or data corruption.
  • GolDDranks 4y ago
    The advantage w.r.t references is that with Slotmap, you can express cyclical data structures, whereas with references you can't. The advantage w.r.t plain Vec and juggling integer indices is that unlike integers, Slotmap keeps track of the "identity" of the stored object; the keys are unique to that object, and you can't accidentally refer to a wrong object with them. > errors risk being silent references to wrong objects Slotmap is specifically designed to prevents this. I recommend you to read its documentation; the generational indices system is quite nice!
    • afiori 4y ago
      > Slotmap keeps track of the "identity" of the stored object (I am not sure if slotmap uses this strategy) To give more details some of these data structures use generational indexes, a pair (generation, index) where index is a plain index of the underlying vector and generation is a bookkeeping counter of how many times you have allocated a value to that index. These two values can be combined in a single 32bit-64bit value but additional memory would be required to keep track of the counter. E.g. with a vector of length 2 {meta: [0,0], data:[...]} malloc -> (1,0) {meta: [1,0], data:[...]} malloc -> (1,1) {meta: [1,1], data:[...]} free(0) {meta: [2,1], data:[...]} malloc -> (3,0) {meta: [3,1], data:[...]} free(0) {meta: [4,1], data:[...]} malloc -> (5,0) {meta: [5,1], data:[...]} free(0) free(1) {meta: [6,2], data:[...]} malloc -> (7,0) malloc -> (3,1) {meta: [7,3], data:[...]} This way if you tried to access the pointer (5,0) the library can check that at index zero of the meta array the generation is 7 and conclude that you are doing a use after free (in this example even generations denote unallocated memory). This is a description of a very simplified algorithm.
    • fulafel 4y ago
      I meant counted references that were mentioned as an alternative in the GP comment. A generation count indeed could mitigate "use after free" style bugs, but may have a high false negative ratio if many/most objects have same generation. But a glance at slotmap docs didn't yield any hits for a generation I'd being used, do you have a specific link?
• dusklight 4y ago
  what do most people use for a generic graph / tree library in rust?
  • gpm 4y ago
    For "proper" graphs, petgraph: https://crates.io/crates/petgraph https://crates.io/crates/petgraph For trees without parent pointers: Just roll your own along the lines of the following. This fits nicely into rust's ownership semantics struct Node<T> { children: Vec<Node<T>> } For trees with parent pointers, I'm not sure what's most common. Potentially Rc with Weak, potentially petgraph, maybe something else.