5 ms·

> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can dev

> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serialization (serde) * network requests (request) There are de-facto base crates in the ecosystem.

pjmlp 7y ago
Do they also compile and run across all platforms supported by rust compiler? Because that is the biggest asset from stuff being in the standard library.
- Ygg2 7y ago
  No, but not all parts of std run on all supported platforms. To clarify, there are different levels of support on different platforms.
  - pjmlp 7y ago
    Then it already starts with a failure of quality gate of what goes into std.
    - nicoburns 7y ago
      Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.
      - pjmlp 7y ago
        So do Basic, Ada, Pascal, C and C++ as well, and yet they have richer standard libraries, with deployment profiles.
        deleted 7y ago
        [deleted]
        floatboth 7y ago
        Since when does libc include "rich" things like regex, serialization and http?? Even C++ standard lib is mostly containers and algorithms. libc is barely a standard library, it's almost nothing.
        pjmlp 7y ago
        C might not include those specific examples, but POSIX + libc already include plenty of stuff. C++ surely does include regex, with serialisation and http scheduled for C++23, or with luck with a TR as intermediate delivery. Although serialisation depends on static reflection being finalized as well.
        Ygg2 7y ago
        Still, it implies C fails, because you don't get POSIX on all available platforms. I think the definition is meaningless. Rust spends huge amount of resources to test itself and its surrounding ecosystem on tier 1 platforms. I'm fairly certain regex from c++ std will run like crap, if at all on something with 4MB of RAM.
        pjmlp 7y ago
        Except the small detail that C's POSIX support is much wider than Rust's tier 1 platforms. I am fairly certain that without profiling and defining a test configuration for a set of specific C++ compilers / standard C++ library I won't assert anything about std::regex performance with 4 MB of RAM.
        7y ago
    - Ygg2 7y ago
      Not exactly. Rust can be made to run on 16-bit toaster or even OsIJustWrote. Just because it can be run, doesn't mean Rust std lib devs will support 16-bit toasters or OsIJustWrote. Each platform has different levels of support. Primary being Windows, Mac and Linux, where every pure Rust crate runs. Std lib makes certain reasonable assumptions, for which it works e.g. malloc exists and panic! is implenented.
kd5bjo 7y ago
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes explicit future compatibility policies. Unfortunately, I can’t find an index of only the crates maintained by the Rust team. Serde is obviously popular, but at first glance is a giant Swiss Army knife that will likely have lots of updates to keep track of that are completely unrelated to my project (whatever it is). If I search for JSON, I get an exact match result of the json crate, followed by a bunch of serde-adjacent crates, but not serde itself. Request hasn’t been updated in 4 years, and has a total of less than 7000 downloads.
- Freak_NL 7y ago
  That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.
  - kd5bjo 7y ago
    It’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them. Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experimental library is the right choice. The trouble is figuring out which I’m looking at.
    - xenocratus 7y ago
      I'm not sure I follow these concerns about "working in the future" - as long as you specify versions that work for you in your Cargo.toml file, that should work at any point in the future given that you use Rust 1.x. If you'll want to update to always be on the latest version of each crate, well that discomfort about them potentially not working is part of the price.

pjmlp 7y ago

Do they also compile and run across all platforms supported by rust compiler? Because that is the biggest asset from stuff being in the standard library.

Ygg2 7y ago
No, but not all parts of std run on all supported platforms. To clarify, there are different levels of support on different platforms.
- pjmlp 7y ago
  Then it already starts with a failure of quality gate of what goes into std.
  - nicoburns 7y ago
    Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.
    - pjmlp 7y ago
      So do Basic, Ada, Pascal, C and C++ as well, and yet they have richer standard libraries, with deployment profiles.
      - deleted 7y ago
        [deleted]
      - floatboth 7y ago
        Since when does libc include "rich" things like regex, serialization and http?? Even C++ standard lib is mostly containers and algorithms. libc is barely a standard library, it's almost nothing.
        pjmlp 7y ago
        C might not include those specific examples, but POSIX + libc already include plenty of stuff. C++ surely does include regex, with serialisation and http scheduled for C++23, or with luck with a TR as intermediate delivery. Although serialisation depends on static reflection being finalized as well.
        Ygg2 7y ago
        Still, it implies C fails, because you don't get POSIX on all available platforms. I think the definition is meaningless. Rust spends huge amount of resources to test itself and its surrounding ecosystem on tier 1 platforms. I'm fairly certain regex from c++ std will run like crap, if at all on something with 4MB of RAM.
        pjmlp 7y ago
        Except the small detail that C's POSIX support is much wider than Rust's tier 1 platforms. I am fairly certain that without profiling and defining a test configuration for a set of specific C++ compilers / standard C++ library I won't assert anything about std::regex performance with 4 MB of RAM.
        7y ago
  - Ygg2 7y ago
    Not exactly. Rust can be made to run on 16-bit toaster or even OsIJustWrote. Just because it can be run, doesn't mean Rust std lib devs will support 16-bit toasters or OsIJustWrote. Each platform has different levels of support. Primary being Windows, Mac and Linux, where every pure Rust crate runs. Std lib makes certain reasonable assumptions, for which it works e.g. malloc exists and panic! is implenented.

kd5bjo 7y ago

As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes explicit future compatibility policies. Unfortunately, I can’t find an index of only the crates maintained by the Rust team. Serde is obviously popular, but at first glance is a giant Swiss Army knife that will likely have lots of updates to keep track of that are completely unrelated to my project (whatever it is). If I search for JSON, I get an exact match result of the json crate, followed by a bunch of serde-adjacent crates, but not serde itself. Request hasn’t been updated in 4 years, and has a total of less than 7000 downloads.

Freak_NL 7y ago
That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.
- kd5bjo 7y ago
  It’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them. Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experimental library is the right choice. The trouble is figuring out which I’m looking at.
  - xenocratus 7y ago
    I'm not sure I follow these concerns about "working in the future" - as long as you specify versions that work for you in your Cargo.toml file, that should work at any point in the future given that you use Rust 1.x. If you'll want to update to always be on the latest version of each crate, well that discomfort about them potentially not working is part of the price.