6 ms·

> Having a decent, well maintained, stdlib that contains "the basics" that one would expect in any 21st century programming language is sorely missing from Rust

> Having a decent, well maintained, stdlib that contains "the basics" that one would expect in any 21st century programming language is sorely missing from Rust, and from my personal perspective is something that would draw me back to Rust for another go at learning it. What would you like to see in that? Genuinely curious, I've considered putting something together that's just a meta-crate that pulls in some others.

frockington1 5y ago
Personally I would like a standard http library that has async and non async methods. One of the things that initially turned me away from Rust was the complexity of finding a library to use for simple http requests. I know this is also a strength, but it makes the intro days incredibly challenging
- staticassertion 5y ago
  I wonder if that's a discovery issue. Having used rust for years the quick answer would be 'reqwest', but I guess there's not really any way someone would know that just jumping into the language.
  - wongarsu 5y ago
    Crates.io is great, but it certainly has a discoverability issue. Even knowing about reqwest it's far from trivial to conjure up a search that yields reqwest on the first result page. And I'm sorely missing features like "crates that use this also use" and "instead of this crate, others use". If I had infinite time on my hands it would be a fun exercise to try to improve on it.
    - tempest_ 5y ago
      I disagree that is hard to find this. Searching "Http request in rust" for me yields the the rust cookbook on the first result, which is using reqwest! (https://rust-lang-nursery.github.io/rust-cookbook/web/clients/requests.html https://rust-lang-nursery.github.io/rust-cookbook/web/client...) Regardless I agree that crates.io could have some more features but I am not sure how useful I would find a recommendation engine.
      - staticassertion 5y ago
        Right, but isn't it a bit of a shame that I search "http" in crates.io, the site that theoretically should be serving the "find a crate" use case, and I don't get suggestions that are useful?
    - dureuill 5y ago
      there is lib.rs that I find much more efficient to discover crates. Requests is currently #6 in its Web programming > HTTP client category[0]. The download counts, number of contributors, version history, and dependent crates is also prominently displayed. [0]: https://lib.rs/web-programming/http-client https://lib.rs/web-programming/http-client
traceroute66 5y ago
> What would you like to see in that? Genuinely curious I see someone else has got there before me and my answer would not be dissimilar. Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. Beyond that (if its not there already) basic tools to enable out-of-the-box CLI writing (e.g. flags etc.)
- bajsejohannes 5y ago
  > Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have: * an outdated HTTP library (look at how "everyone" is using a 3rd party HTTP library in python) * a JSON library no one uses (everyone used XML, now it's out of fashion. And JSON has obvious problems!) * Old cryptographic standards that you'd rather not use
  - FpUser 5y ago
    >"The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have:" Perfect reason for not writing any software. None would work for 20 years without maintenance (there are some exceptions of course).
    - mplanchard 5y ago
      No, it’s the perfect reason for not pulling software into the standard library, which has strong backwards compatibility guarantees and cannot be as cavalier about changing interfaces and deprecations as external crates.
lumost 5y ago
A Collections grouping of common data structures and macros would be useful. There are so many different idiomatic ways to instantiate a type in rust that a crate with a common calling convention for most data structures would be very useful.
- Elinvynia 5y ago
  You mean like this? https://doc.rust-lang.org/std/collections/index.html https://doc.rust-lang.org/std/collections/index.html
  - nicoburns 5y ago
    I think they want something like a ‘map!()’ macro.
  - lumost 5y ago
    Sibling nailed it but I can’t reply on that post. There are variations such as Vec!, map! Macros collect_vec, collect_map etc. It would be great to have a unified interface that exposes a common set of instantiation mechanisms and apis. Other lib authors should be able to implement this api and get the same calling conventions.
rastignack 5y ago
good json parsing is important these days. crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Right now in rust we rely on rust bindings to c libs.
- traceroute66 5y ago
  > crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Indeed. I would almost put my neck above the parapet and say that in the 21st century any programming language worthy of its name should come with decent crypto out of the box. Crypto is no longer an option these days.
- SAI_Peregrinus 5y ago
  I disagree about golang's crypto being good. It includes insecure functions like md5 and sha1 that have no place in a crypto library. They should be in some other part of the library (maybe add a "legacy" section) or just not included at all. The go stdlib crypto is also makes the (common) mistake of exposing unsafe primitives (like raw AES without a mode of operation needed to use it for encryption) at the top level of their various sections instead of a well-documented "unsafe" or "hazardous" section. And it's missing useful well-vetted high-performance options like AES-OCB (which recently went out of patent).
  - rastignack 5y ago
    Well sha1 and md5 are used all over the place so supporting them makes a lot of sense. Most of your points are related to documentation, and a bit patronizing. For all I care most of the functionality is there, fast and reasonably well designed.
nicoburns 5y ago
I would suggest that an opinionated website documenting a curation of crate choices might be better than a crate (which would be a pain technically). I’ve been considering making one if you’d be interested in collaborating.
- staticassertion 5y ago
  Happy to discuss. I'm sick so I'm being extra terrible about responding to emails (and I'm about to go to sleep at 6am -_-) but feel free to reach out. I could see a website being much simpler to maintain.
- woile 5y ago
  I was actually thinking as a learning exercise, to go through python docs and create a rust book covering the needs of a python developer with different crates. If the book is versioned you can easily remove and add new crates. But I've been busy at work...
derkoe 5y ago
I think serde should be part of the stdlib. A http server and client library is also really a must-have today. Maybe some abstraction for SQL database drivers. Some other candidates include: logging, anync runtime (Tokyo), random generator, regex
- the_mitsuhiko 5y ago
  Let me give you some contrasting views on this: we already know that serde has (serious) limitations and sooner or later a completely new version will be needed. HTTP and Client library will not make sense unless async is also in the core. Moving async in the core is going to raise serious problems for people trying to port this to new ecosystems and there is not even agreement on exactly how async should continue into the future. In fact, there are people (like me) who are very happily pushing back on moving stuff into the standard library unless it's clear that the code there can live for 30 years. And I do not see this for almost all the things you just mentioned.
  - tempest_ 5y ago
    What are Serde's serious limitations?
    - the_mitsuhiko 5y ago
      You're constrained by the internal serde data model. For instance serde has no bignum in the data model, so you can't express it in that data model which requires awful workarounds. I went into the types of abuses necessary here a bit: https://lucumr.pocoo.org/2021/11/14/abusing-serde/ https://lucumr.pocoo.org/2021/11/14/abusing-serde/
- deleted 5y ago
  [deleted]
- heavenlyblue 5y ago
  What being a part of standard library makes the library better?

frockington1 5y ago

Personally I would like a standard http library that has async and non async methods. One of the things that initially turned me away from Rust was the complexity of finding a library to use for simple http requests. I know this is also a strength, but it makes the intro days incredibly challenging

staticassertion 5y ago
I wonder if that's a discovery issue. Having used rust for years the quick answer would be 'reqwest', but I guess there's not really any way someone would know that just jumping into the language.
- wongarsu 5y ago
  Crates.io is great, but it certainly has a discoverability issue. Even knowing about reqwest it's far from trivial to conjure up a search that yields reqwest on the first result page. And I'm sorely missing features like "crates that use this also use" and "instead of this crate, others use". If I had infinite time on my hands it would be a fun exercise to try to improve on it.
  - tempest_ 5y ago
    I disagree that is hard to find this. Searching "Http request in rust" for me yields the the rust cookbook on the first result, which is using reqwest! (https://rust-lang-nursery.github.io/rust-cookbook/web/clients/requests.html https://rust-lang-nursery.github.io/rust-cookbook/web/client...) Regardless I agree that crates.io could have some more features but I am not sure how useful I would find a recommendation engine.
    - staticassertion 5y ago
      Right, but isn't it a bit of a shame that I search "http" in crates.io, the site that theoretically should be serving the "find a crate" use case, and I don't get suggestions that are useful?
  - dureuill 5y ago
    there is lib.rs that I find much more efficient to discover crates. Requests is currently #6 in its Web programming > HTTP client category[0]. The download counts, number of contributors, version history, and dependent crates is also prominently displayed. [0]: https://lib.rs/web-programming/http-client https://lib.rs/web-programming/http-client

traceroute66 5y ago

> What would you like to see in that? Genuinely curious I see someone else has got there before me and my answer would not be dissimilar. Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. Beyond that (if its not there already) basic tools to enable out-of-the-box CLI writing (e.g. flags etc.)

bajsejohannes 5y ago
> Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have: * an outdated HTTP library (look at how "everyone" is using a 3rd party HTTP library in python) * a JSON library no one uses (everyone used XML, now it's out of fashion. And JSON has obvious problems!) * Old cryptographic standards that you'd rather not use
- FpUser 5y ago
  >"The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have:" Perfect reason for not writing any software. None would work for 20 years without maintenance (there are some exceptions of course).
  - mplanchard 5y ago
    No, it’s the perfect reason for not pulling software into the standard library, which has strong backwards compatibility guarantees and cannot be as cavalier about changing interfaces and deprecations as external crates.

lumost 5y ago

A Collections grouping of common data structures and macros would be useful. There are so many different idiomatic ways to instantiate a type in rust that a crate with a common calling convention for most data structures would be very useful.

Elinvynia 5y ago
You mean like this? https://doc.rust-lang.org/std/collections/index.html https://doc.rust-lang.org/std/collections/index.html
- nicoburns 5y ago
  I think they want something like a ‘map!()’ macro.
- lumost 5y ago
  Sibling nailed it but I can’t reply on that post. There are variations such as Vec!, map! Macros collect_vec, collect_map etc. It would be great to have a unified interface that exposes a common set of instantiation mechanisms and apis. Other lib authors should be able to implement this api and get the same calling conventions.

rastignack 5y ago

good json parsing is important these days. crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Right now in rust we rely on rust bindings to c libs.

traceroute66 5y ago
> crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Indeed. I would almost put my neck above the parapet and say that in the 21st century any programming language worthy of its name should come with decent crypto out of the box. Crypto is no longer an option these days.
SAI_Peregrinus 5y ago
I disagree about golang's crypto being good. It includes insecure functions like md5 and sha1 that have no place in a crypto library. They should be in some other part of the library (maybe add a "legacy" section) or just not included at all. The go stdlib crypto is also makes the (common) mistake of exposing unsafe primitives (like raw AES without a mode of operation needed to use it for encryption) at the top level of their various sections instead of a well-documented "unsafe" or "hazardous" section. And it's missing useful well-vetted high-performance options like AES-OCB (which recently went out of patent).
- rastignack 5y ago
  Well sha1 and md5 are used all over the place so supporting them makes a lot of sense. Most of your points are related to documentation, and a bit patronizing. For all I care most of the functionality is there, fast and reasonably well designed.

nicoburns 5y ago

I would suggest that an opinionated website documenting a curation of crate choices might be better than a crate (which would be a pain technically). I’ve been considering making one if you’d be interested in collaborating.

staticassertion 5y ago
Happy to discuss. I'm sick so I'm being extra terrible about responding to emails (and I'm about to go to sleep at 6am -_-) but feel free to reach out. I could see a website being much simpler to maintain.
woile 5y ago
I was actually thinking as a learning exercise, to go through python docs and create a rust book covering the needs of a python developer with different crates. If the book is versioned you can easily remove and add new crates. But I've been busy at work...

derkoe 5y ago

I think serde should be part of the stdlib. A http server and client library is also really a must-have today. Maybe some abstraction for SQL database drivers. Some other candidates include: logging, anync runtime (Tokyo), random generator, regex

the_mitsuhiko 5y ago
Let me give you some contrasting views on this: we already know that serde has (serious) limitations and sooner or later a completely new version will be needed. HTTP and Client library will not make sense unless async is also in the core. Moving async in the core is going to raise serious problems for people trying to port this to new ecosystems and there is not even agreement on exactly how async should continue into the future. In fact, there are people (like me) who are very happily pushing back on moving stuff into the standard library unless it's clear that the code there can live for 30 years. And I do not see this for almost all the things you just mentioned.
- tempest_ 5y ago
  What are Serde's serious limitations?
  - the_mitsuhiko 5y ago
    You're constrained by the internal serde data model. For instance serde has no bignum in the data model, so you can't express it in that data model which requires awful workarounds. I went into the types of abuses necessary here a bit: https://lucumr.pocoo.org/2021/11/14/abusing-serde/ https://lucumr.pocoo.org/2021/11/14/abusing-serde/
deleted 5y ago
[deleted]
heavenlyblue 5y ago
What being a part of standard library makes the library better?