21 ms·

Blessed.rs – An unofficial guide to the Rust ecosystem

311 points by andrewshadura 4y ago

Aeolun 4y ago
The thing that stands out to me most is that Rust still doesn’t seem to have settled on a single way to do async… It’s becoming a trope at this point.
lijogdfljk 4y ago
Tangent, i really enjoy the design of that site. Crisp, readable, simple. Maybe a bit low on contrast, but not terribly so.
- mpalmer 4y ago
  Agreed; I'd give it full marks if it were optimized for mobile.
  - nicoburns 4y ago
    I've added some basic mobile styling :) Probably could be better, but I think this makes it somewhat readable on mobile.
echelon 4y ago
See also: https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust This list is currently far more comprehensive, and it's filled with a lot of high-quality crates for a wide variety of common tasks. I would like to see this list transformed into a navigable website. It'd also be nice to include code samples (eg. I recently had to investigate each test mocking library directly, and a high level summary or comparison would have helped).
- Xeoncross 4y ago
  The problem with awesome-?? sites is that they list 18 error libs without actually stating which one is has the most use by high profile projects or some other "recommended" metric. Github search is much better for finding quality libraries as you can filter by star count, age, recency, last commit, and see fork numbers. It's not perfect, but generally cuts the work down significantly and then you can finish evaluation the projects by clicking through to read the stats of each one.
  - bravetraveler 4y ago
    Indeed, or listing quite a few clearly abandoned projects. Awesome for learning perhaps, but depending on the case... perhaps not something I'd readily suggest using The Wayland list comes to mind, while I don't have any specific examples
- tptacek 4y ago
  Awesome Rust doesn't solve the problem this page sets out to solve. Rust has a tiny standard library, and (many would say) there needs to be a de facto consensus on the best mainstream libraries to solve "the rest of it" --- serialization, error handling, logging, &c. An "Awesome" list can help you find 6 different very interesting libraries for each of those problems, but that's not solving the big problem, because everyone will pick a different library; without a consensus pick, some of those libraries can lose momentum, which is a problem 2 years down the road when the maintainer packs up shop. What you'd want, if you're the audience for this page, is just a list of straight-up "use this library" picks, in the hopes that those libraries will be stable and maintained indefinitely, and will develop supportive communities.
kitd 4y ago
Good work. But I can't help thinking this could or (should even) be under the auspices of crates.io. Provide a way to categorise crates and highlight commonly-used or trusted crates.
- jgilias 4y ago
  I’ve found that search in crates.io works surprisingly well for me. I just make a few searches with different keywords I feel make sense for what I’m looking for, look at download characteristics, and that’s it. A curated list can quickly get outdated. I do like this website though!
Sphax 4y ago
I'm still not sure what crate I should use for time between time and chrono, and searching the internet gives me conflicting information: This site says about the time crate: "The original datetime crate which was split out of std pre-rust-1.0" but as far as I can tell the time crate as it is now is not the original crate and is maintained. The book zero2prod uses chrono. What's the recommended crate to use for time today ?
- k__ 4y ago
  Maybe, both are okay and it's just a matter of taste?
- conradludgate 4y ago
  Both are maintained and fairly equivalent in API. chrono is getting an upgrade soon in 0.5 that should make it slightly easier to use too. I've made some PRs recently to chrono, the new maintainer is very good
- dochtman 4y ago
  Yes, the time crate was rebooted after 0.1 and got a new maintainer. I think we're starting to do better again with Chrono, hopefully it won't take us too long to get out a solid 0.5 release. (I'm one of the current Chrono maintainers -- the previous maintainer burnt out on the project earlier this year, at which point the project sorely needed some TLC.)
  - nicoburns 4y ago
    Do you think there's any possibility of `time` and `chrono` merging at some point? (or one depending on the other and providing a superset of functionality). It's rather confusing having two de-facto datetime libraries in the Rust ecosystem, and as far as I can see there isn't any major difference in philosophy or scope between the two libraries?
    - dochtman 4y ago
      One depending on the other seems like the worst of both worlds: more code to compile for everyone. Personally I still prefer chrono's API; chrono is also much more conservative about the MSRV (currently at 1.38) whereas time consistently bumps to N - 3, which seems like a meaningful difference. time depends on the libc timezone parsing with some fairly involved workarounds to avoid hitting undefined behavior, while we incorporated time zone parsing in Rust with some caching for chrono. So I think these are meaningful differences -- feels unlikely that these projects will merge.
jaxrtech 4y ago
This is fantastic. This is almost identical to what I've been having to remember in the back of my head every time I go create a new project haha. I've also settled on the anyhow + thiserror deal. Rust is not batteries included -- it's nice for those experienced or beginners to know which batteries to use without going on some expedition to find them. The more challenging part is working in niche areas, https://lib.rs https://lib.rs definitely helps as well.
kjaleshire 4y ago
This reads suspiciously similar to the Rust Platform proposal in 2016 [0] and was concensus-rejected by the community [1]. [0] https://news.ycombinator.com/item?id=12177002 https://news.ycombinator.com/item?id=12177002 [1] https://internals.rust-lang.org/t/follow-up-the-rust-platform/3782 https://internals.rust-lang.org/t/follow-up-the-rust-platfor...
gavinray 4y ago
It's worth mentioning: Under "Async Executors", for "io_uring" there is only "Glommio" I recently found out that ByteDance has a competitor library which supposedly has better performance: https://github.com/bytedance/monoio https://github.com/bytedance/monoio https://github.com/DataDog/glommio/issues/554 https://github.com/DataDog/glommio/issues/554
mrits 4y ago
Bless you. I keep a boilerplate crate around like this with everything I frequently use already imported with some notes about why I chose it over alternatives. I wonder if you would take some pull requests that let you drill down into some of these libs for more details on alternatives
freedomben 4y ago
I did C/C++ for years 10+ years ago, but since learning Ruby and then Elixir I've loved the functional approach. I've thought a lot about rust over the years but I haven't yet found a project where it made more sense than Ruby or Elixir did given the learning effort. I've done a few projects in Go and while I like it's simplicity, I dislike the verbosity and lack of functional features. Does anybody else have a similar background that can share their opinion/love level of rust? Rust people: do you use Rust for (nearly) everything? i.e. does it feel very general purpose, or if you are doing something that will be entirely network I/O bound anyway do you reach for something else?
- mcronce 4y ago
  I came from PHP, Python, and Go (in that order) with very limited experience in both C and C++ and now use Rust for everything with one exception - a scraper for mint.com that uses https://github.com/mintapi/mintapi https://github.com/mintapi/mintapi. That has a lot going on, including spinning up a headless browser, and my code is virtually trivial, so the benefits of porting it to Rust are limited, and the work would be pretty significant. As far as things I typically make, database-backed HTTP APIs are probably the most common, and influxdb collectors second most common.
  - freedomben 4y ago
    Thanks! Is there a specific rust framework you would recommend for HTTP APIs? Or is the standard lib good enough that you don't really need one?
    - mcronce 4y ago
      I always use actix-web. warp comes pretty highly recommended as well, although I haven't personally tried it.
- quake 4y ago
  I can probably chime in here. I have used Rust professionally for 2 years but I've been working with it as a hobby for 3. Experience predominantly in C/C++ embedded and systems environments. I've used Rust for *nix based IOT programs to ingest data from different sources (network I/O, serial, CAN, files, etc), as well as for bare-metal embedded development. I've also made some dinky webservers as an exercise and various random tooling. It's a very, very flexible language, once you get over its quirks. I found myself using it to make tools that I would usually turn to Python for. I'm quite impressed with how "high level" the language feels despite being able to work with low-level concepts. Simple stuff like mapping iterators and the Option<T> type while working without an OS is a fantastic feeling. As most people will likely say, take Rust for a test drive with a basic project to decide for yourself. I would say to keep it simple and not go down the async route as your first foray, though.
GolDDranks 4y ago
Some more I'd wish to see on the page: - slotmap - memchr - bytecount - rouille - csv
- epage 4y ago
  Doesn't bstr replace memchr? Unsure if it replaces bytecount.
  - burntsushi 4y ago
    No. bstr depends on memchr. bytecount is faster than memchr for counting occurrences for bytes. It doesn't have to stop and report offsets. It can just zip through and count.
- maxbond 4y ago
  Submit a PR or open an issue! https://github.com/nicoburns/blessed-rs https://github.com/nicoburns/blessed-rs
endorphine 4y ago
Curious to know the rationale behind the "batteries not included" approach. One of the advantages of Go imho is it's solid stdlib, which includes production-ready HTTP server/client, JSON, XML, crypto libraries and more.
- rapsey 4y ago
  Because it requires that library with that API be maintained forever. Guaranteeing it eventually becoming unused because the language is evolving and better APIs can be made. For instance mpsc and mutex libs are commonly not used because crossbeam-channels and parking_lot libraries are better than what Rust ships with.
  - maxbond 4y ago
    In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/csv.html#csv.Sniffer https://docs.python.org/3/library/csv.html#csv.Sniffer This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.
    - pjmlp 4y ago
      I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.
      - maxbond 4y ago
        Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.
root_axis 4y ago
This list recommends the tracing package over the slog package. I've only ever used slog, so I'd be interested to hear why some people prefer tracing to slog.
- msvan 4y ago
  From the slog Github repo: > You might consider using tracing instead. It's been a while since slog was created and it served Rust community well all this time. It remains a stable, featureful and battle-tested library, used in many important projects. > In last few years, another ecosystem for Rust was created with similar features and a very good support for debugging async code and already larger dev team and community. > Please check tracing and see if it is more suitable for your use-case. It seems that it is already a go-to logging/tracing solution for Rust. > Reasons you might want to stick with slog anyway: > async support doesn't benefit you > you consider mature, stable code & API a plus > it has some features that tracing is missing > great performance (I have NOT done any comparison, but slog's performance is very good).
  - root_axis 4y ago
    Thanks!
papascrubs 4y ago
Does something like this exist for other languages (Go/Python etc)? This seems well curated, looking for community input vs digging on a search engine. I'm all for "batteries not included", but every time I dip my toes into languages like that, it can take a bit of work to find out common libraries that the majority is using. Not trying to re-ivent the wheel. It's nice to see opinionated takes on things in one central location.
- dimitar 4y ago
  The clojure toolbox: https://www.clojure-toolbox.com/ https://www.clojure-toolbox.com/ There also the various awesome lists on GitHub, but they are not always well curated
  - kibwen 4y ago
    Note that they're literally called "Awesome" lists, that's not an adjective describing the lists themselves. :P
- jmfurlott 4y ago
  Curious about one for python as well
wging 4y ago
Well, this has already paid off for me, even though I thought I knew most of it. I recently built a toy chat app with tungstenite+websockets, and am now kind of kicking myself because I could probably have just used axum. At least I got some good practice and learned a couple things by doing it a more 'manual' way, and get to compare it to axum's websocket support. Something else I'd like to see is a tad more clarity on how the recommended channel implementations relate to std::mpsc::channel and tokio::mpsc::channel - the recommended options seem to claim to be better than their respective std/tokio counterparts, but blessed.rs itself doesn't explicitly make that claim. Should it? (I've only ever used std::mpsc and tokio::mpsc, and not in a production context.)
- necubi 4y ago
  Crossbeam channels are better in just about every way than std::sync::mpsc. They're faster, have more features (including supporting multiple consumers), and have a better API. Tokio vs crossbeam/std::sync is a bit of a different question. Using the tokio implementations let you await (i.e., asynchronously block) on a channel, whereas the others will block the thread. So within async code, use tokio for use cases where you may have a blocking operation (writing to a bounded queue or waiting for a message). Otherwise, use crossbeam.
  - wging 4y ago
    I didn't mean to imply these were all substitutes for each other - rather that there are both sync and async channels in the list and it seems worthwhile to compare the sync ones against std::sync::mpsc, and the async ones against tokio::sync::mpsc. Not to mention the sync/async ones against each other (flume and postage both have async capabilities). I do think the site does a decent job of calling out that there is a difference between the two types of channel.
iot_devs 4y ago
I ways wonder what would happen if you were to promise maintenance of those packages and improved doc, and then slap a pricing page for corporate.
woile 4y ago
This is great! I wish it was a bit more opinionated and gave for example 1 or 2 http server option(s). I don't know under which criteria though
- nicoburns 4y ago
  The options are ordered, so you can effectively get this by just reading the top 2 and ignoring the others. Perhaps this could be made clearer though. I've been trying to balance keeping the list short with providing some context about why you perhaps shouldn't other options.
  - woile 4y ago
    I think the approach you've taken by providing this document, allows you to give 1 option, and when there's something better you just change it. Ideally if you follow semver and there's something replacing something else, you could introduce a breaking change. And if you let people navigate different versions, they could see how things changed over time. Thanks for it btw!
pornel 4y ago
I've developed a list of common crates based on the number of active users: https://lib.rs/std https://lib.rs/std
- bogeholm 4y ago
  And thank you for that! Love lib.rs
- CameronNemo 4y ago
  How do you determine what an active user is?
  - pornel 4y ago
    Roughly that’s number of unique crate owners of reverse dependencies that have been updated within the last couple of years, plus some other factors like downranking crates that lose popularity.
- chlorion 4y ago
  This is very useful! Thanks for sharing! I've been looking for a list of semi-blessed crates like this for a long time. Before finding this and the OP's site I looked at the dependencies of rustc and cargo and considered those to be mostly trusted.
- 3a2d29 4y ago
  Very cool!
nicoburns 4y ago
This is my project (although I didn't submit this to HN), AMA I consider quite incomplete at this point (but hopefully already useful). There are several categories of crate that just aren't covered yet (suggestions very welcome, either here or on the github repo https://github.com/nicoburns/blessed-rs https://github.com/nicoburns/blessed-rs). I'd also like to add more hand curated content such as: - Installation and developer environment setup - Link to learning resources (books, projects, etc) - Explanations of the community (reddit, TWIR, discourse, github, zulip, etc) - Themed guides (backend web development, CLI tools, game development, etc) I want to put together more guidance on how to contribute, and gradually transition this into more of a community maintained model over time, but I haven't had a chance to do this yet.
- outside1234 4y ago
  Thanks for putting this together. Some other ideas: * Config: dotenvy * Database: sqlx (async), diesel (sync, ORM) * gRPC: prost (protobuf library)
  - TotempaaltJ 4y ago
    Another for config: https://crates.io/crates/config https://crates.io/crates/config
  - echelon 4y ago
    +1 for sqlx. Native SQL queries that are typechecked at compile time.
    - maxbond 4y ago
      sqlx is awesome but I'd add the small caveat that it has an annoying sharp edge with sqlite where it relies on sqlite's loose typing, but if you want to use the recent strict feature[1] (which enforces type & check constraints), you need to use the specific underlying types (eg, you need to specify INTEGER, not DATETIME). In which case, I'd recommend the excellent rusqlite. You'll also be able to use all sorts of advanced sqlite features that way, like writing functions in Rust that you can call from your queries[2]. [1] https://www.sqlite.org/stricttables.html https://www.sqlite.org/stricttables.html [2] https://docs.rs/rusqlite/latest/rusqlite/functions/index.html https://docs.rs/rusqlite/latest/rusqlite/functions/index.htm...
mwcampbell 4y ago
> Older binding to the windows APIs. Unofficial, but more complete than windows-rs What is windows-rs missing that's in winapi? So far I've found everything I need in windows-rs, including some pretty obscure corners of the massive Windows API.
bnewbold 4y ago
This seems like a good contribution. It would great if one of these "lists of blessed crates" itself becomes blessed and sticks around! This list seems like it was created by somebody with "good taste", and I enjoy the amount of description. https://lib.rs https://lib.rs has some basic features to make it faster to sniff test various crates. Eg, I like being able to see a summary of the authors, and things like "maintained by RustCrypto team" just looking at the summary. My suspicion is that some concept of graph centrality (perhaps via authors?), and perhaps counting applications which aren't usually distributed via cargo (this contributing to crates.io downloads), could both yield a better popularity metric. But the trend stuff is pretty reasonable already. Some related efforts at documenting pseudo-official crates (in contrast to gigantic "awesome" lists) are the "areweX yet" pages (https://www.arewewebyet.org/ https://www.arewewebyet.org/), the Rust Cookbook (https://rust-lang-nursery.github.io/rust-cookbook/ https://rust-lang-nursery.github.io/rust-cookbook/), and the Rust Lang Nursery (https://github.com/rust-lang-nursery https://github.com/rust-lang-nursery). Here is an ancient github issue from way back in 2014 discussing the idea of "official" crates: https://github.com/rust-lang/cargo/issues/934 https://github.com/rust-lang/cargo/issues/934
tmpfs 4y ago
This is fantastic! My only nitpick would be that the `time` crate is now fully featured and can be a drop in replacement for `chrono`. It also seems to be more actively maintained than `chrono`; i would recommend preferring `time` for new projects. I wish this existed when i was starting out with Rust ;)
pc2g4d 4y ago
Really dig this. Learned some things about my own dependencies!

311 points by andrewshadura 4y ago

The thing that stands out to me most is that Rust still doesn’t seem to have settled on a single way to do async… It’s becoming a trope at this point.

lijogdfljk 4y ago

Tangent, i really enjoy the design of that site. Crisp, readable, simple. Maybe a bit low on contrast, but not terribly so.

mpalmer 4y ago
Agreed; I'd give it full marks if it were optimized for mobile.
- nicoburns 4y ago
  I've added some basic mobile styling :) Probably could be better, but I think this makes it somewhat readable on mobile.

echelon 4y ago

See also: https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust This list is currently far more comprehensive, and it's filled with a lot of high-quality crates for a wide variety of common tasks. I would like to see this list transformed into a navigable website. It'd also be nice to include code samples (eg. I recently had to investigate each test mocking library directly, and a high level summary or comparison would have helped).

Xeoncross 4y ago
The problem with awesome-?? sites is that they list 18 error libs without actually stating which one is has the most use by high profile projects or some other "recommended" metric. Github search is much better for finding quality libraries as you can filter by star count, age, recency, last commit, and see fork numbers. It's not perfect, but generally cuts the work down significantly and then you can finish evaluation the projects by clicking through to read the stats of each one.
- bravetraveler 4y ago
  Indeed, or listing quite a few clearly abandoned projects. Awesome for learning perhaps, but depending on the case... perhaps not something I'd readily suggest using The Wayland list comes to mind, while I don't have any specific examples
tptacek 4y ago
Awesome Rust doesn't solve the problem this page sets out to solve. Rust has a tiny standard library, and (many would say) there needs to be a de facto consensus on the best mainstream libraries to solve "the rest of it" --- serialization, error handling, logging, &c. An "Awesome" list can help you find 6 different very interesting libraries for each of those problems, but that's not solving the big problem, because everyone will pick a different library; without a consensus pick, some of those libraries can lose momentum, which is a problem 2 years down the road when the maintainer packs up shop. What you'd want, if you're the audience for this page, is just a list of straight-up "use this library" picks, in the hopes that those libraries will be stable and maintained indefinitely, and will develop supportive communities.

kitd 4y ago

Good work. But I can't help thinking this could or (should even) be under the auspices of crates.io. Provide a way to categorise crates and highlight commonly-used or trusted crates.

jgilias 4y ago
I’ve found that search in crates.io works surprisingly well for me. I just make a few searches with different keywords I feel make sense for what I’m looking for, look at download characteristics, and that’s it. A curated list can quickly get outdated. I do like this website though!

Sphax 4y ago

I'm still not sure what crate I should use for time between time and chrono, and searching the internet gives me conflicting information: This site says about the time crate: "The original datetime crate which was split out of std pre-rust-1.0" but as far as I can tell the time crate as it is now is not the original crate and is maintained. The book zero2prod uses chrono. What's the recommended crate to use for time today ?

k__ 4y ago
Maybe, both are okay and it's just a matter of taste?
conradludgate 4y ago
Both are maintained and fairly equivalent in API. chrono is getting an upgrade soon in 0.5 that should make it slightly easier to use too. I've made some PRs recently to chrono, the new maintainer is very good
dochtman 4y ago
Yes, the time crate was rebooted after 0.1 and got a new maintainer. I think we're starting to do better again with Chrono, hopefully it won't take us too long to get out a solid 0.5 release. (I'm one of the current Chrono maintainers -- the previous maintainer burnt out on the project earlier this year, at which point the project sorely needed some TLC.)
- nicoburns 4y ago
  Do you think there's any possibility of `time` and `chrono` merging at some point? (or one depending on the other and providing a superset of functionality). It's rather confusing having two de-facto datetime libraries in the Rust ecosystem, and as far as I can see there isn't any major difference in philosophy or scope between the two libraries?
  - dochtman 4y ago
    One depending on the other seems like the worst of both worlds: more code to compile for everyone. Personally I still prefer chrono's API; chrono is also much more conservative about the MSRV (currently at 1.38) whereas time consistently bumps to N - 3, which seems like a meaningful difference. time depends on the libc timezone parsing with some fairly involved workarounds to avoid hitting undefined behavior, while we incorporated time zone parsing in Rust with some caching for chrono. So I think these are meaningful differences -- feels unlikely that these projects will merge.

jaxrtech 4y ago

This is fantastic. This is almost identical to what I've been having to remember in the back of my head every time I go create a new project haha. I've also settled on the anyhow + thiserror deal. Rust is not batteries included -- it's nice for those experienced or beginners to know which batteries to use without going on some expedition to find them. The more challenging part is working in niche areas, https://lib.rs https://lib.rs definitely helps as well.

kjaleshire 4y ago

This reads suspiciously similar to the Rust Platform proposal in 2016 [0] and was concensus-rejected by the community [1]. [0] https://news.ycombinator.com/item?id=12177002 https://news.ycombinator.com/item?id=12177002 [1] https://internals.rust-lang.org/t/follow-up-the-rust-platform/3782 https://internals.rust-lang.org/t/follow-up-the-rust-platfor...

gavinray 4y ago

It's worth mentioning: Under "Async Executors", for "io_uring" there is only "Glommio" I recently found out that ByteDance has a competitor library which supposedly has better performance: https://github.com/bytedance/monoio https://github.com/bytedance/monoio https://github.com/DataDog/glommio/issues/554 https://github.com/DataDog/glommio/issues/554

mrits 4y ago

Bless you. I keep a boilerplate crate around like this with everything I frequently use already imported with some notes about why I chose it over alternatives. I wonder if you would take some pull requests that let you drill down into some of these libs for more details on alternatives

freedomben 4y ago

I did C/C++ for years 10+ years ago, but since learning Ruby and then Elixir I've loved the functional approach. I've thought a lot about rust over the years but I haven't yet found a project where it made more sense than Ruby or Elixir did given the learning effort. I've done a few projects in Go and while I like it's simplicity, I dislike the verbosity and lack of functional features. Does anybody else have a similar background that can share their opinion/love level of rust? Rust people: do you use Rust for (nearly) everything? i.e. does it feel very general purpose, or if you are doing something that will be entirely network I/O bound anyway do you reach for something else?

mcronce 4y ago
I came from PHP, Python, and Go (in that order) with very limited experience in both C and C++ and now use Rust for everything with one exception - a scraper for mint.com that uses https://github.com/mintapi/mintapi https://github.com/mintapi/mintapi. That has a lot going on, including spinning up a headless browser, and my code is virtually trivial, so the benefits of porting it to Rust are limited, and the work would be pretty significant. As far as things I typically make, database-backed HTTP APIs are probably the most common, and influxdb collectors second most common.
- freedomben 4y ago
  Thanks! Is there a specific rust framework you would recommend for HTTP APIs? Or is the standard lib good enough that you don't really need one?
  - mcronce 4y ago
    I always use actix-web. warp comes pretty highly recommended as well, although I haven't personally tried it.
quake 4y ago
I can probably chime in here. I have used Rust professionally for 2 years but I've been working with it as a hobby for 3. Experience predominantly in C/C++ embedded and systems environments. I've used Rust for *nix based IOT programs to ingest data from different sources (network I/O, serial, CAN, files, etc), as well as for bare-metal embedded development. I've also made some dinky webservers as an exercise and various random tooling. It's a very, very flexible language, once you get over its quirks. I found myself using it to make tools that I would usually turn to Python for. I'm quite impressed with how "high level" the language feels despite being able to work with low-level concepts. Simple stuff like mapping iterators and the Option<T> type while working without an OS is a fantastic feeling. As most people will likely say, take Rust for a test drive with a basic project to decide for yourself. I would say to keep it simple and not go down the async route as your first foray, though.

GolDDranks 4y ago

Some more I'd wish to see on the page: - slotmap - memchr - bytecount - rouille - csv

epage 4y ago
Doesn't bstr replace memchr? Unsure if it replaces bytecount.
- burntsushi 4y ago
  No. bstr depends on memchr. bytecount is faster than memchr for counting occurrences for bytes. It doesn't have to stop and report offsets. It can just zip through and count.
maxbond 4y ago
Submit a PR or open an issue! https://github.com/nicoburns/blessed-rs https://github.com/nicoburns/blessed-rs

endorphine 4y ago

Curious to know the rationale behind the "batteries not included" approach. One of the advantages of Go imho is it's solid stdlib, which includes production-ready HTTP server/client, JSON, XML, crypto libraries and more.

rapsey 4y ago
Because it requires that library with that API be maintained forever. Guaranteeing it eventually becoming unused because the language is evolving and better APIs can be made. For instance mpsc and mutex libs are commonly not used because crossbeam-channels and parking_lot libraries are better than what Rust ships with.
- maxbond 4y ago
  In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/csv.html#csv.Sniffer https://docs.python.org/3/library/csv.html#csv.Sniffer This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.
  - pjmlp 4y ago
    I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.
    - maxbond 4y ago
      Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.

root_axis 4y ago

This list recommends the tracing package over the slog package. I've only ever used slog, so I'd be interested to hear why some people prefer tracing to slog.

msvan 4y ago
From the slog Github repo: > You might consider using tracing instead. It's been a while since slog was created and it served Rust community well all this time. It remains a stable, featureful and battle-tested library, used in many important projects. > In last few years, another ecosystem for Rust was created with similar features and a very good support for debugging async code and already larger dev team and community. > Please check tracing and see if it is more suitable for your use-case. It seems that it is already a go-to logging/tracing solution for Rust. > Reasons you might want to stick with slog anyway: > async support doesn't benefit you > you consider mature, stable code & API a plus > it has some features that tracing is missing > great performance (I have NOT done any comparison, but slog's performance is very good).
- root_axis 4y ago
  Thanks!

papascrubs 4y ago

Does something like this exist for other languages (Go/Python etc)? This seems well curated, looking for community input vs digging on a search engine. I'm all for "batteries not included", but every time I dip my toes into languages like that, it can take a bit of work to find out common libraries that the majority is using. Not trying to re-ivent the wheel. It's nice to see opinionated takes on things in one central location.

dimitar 4y ago
The clojure toolbox: https://www.clojure-toolbox.com/ https://www.clojure-toolbox.com/ There also the various awesome lists on GitHub, but they are not always well curated
- kibwen 4y ago
  Note that they're literally called "Awesome" lists, that's not an adjective describing the lists themselves. :P
jmfurlott 4y ago
Curious about one for python as well

wging 4y ago

Well, this has already paid off for me, even though I thought I knew most of it. I recently built a toy chat app with tungstenite+websockets, and am now kind of kicking myself because I could probably have just used axum. At least I got some good practice and learned a couple things by doing it a more 'manual' way, and get to compare it to axum's websocket support. Something else I'd like to see is a tad more clarity on how the recommended channel implementations relate to std::mpsc::channel and tokio::mpsc::channel - the recommended options seem to claim to be better than their respective std/tokio counterparts, but blessed.rs itself doesn't explicitly make that claim. Should it? (I've only ever used std::mpsc and tokio::mpsc, and not in a production context.)

necubi 4y ago
Crossbeam channels are better in just about every way than std::sync::mpsc. They're faster, have more features (including supporting multiple consumers), and have a better API. Tokio vs crossbeam/std::sync is a bit of a different question. Using the tokio implementations let you await (i.e., asynchronously block) on a channel, whereas the others will block the thread. So within async code, use tokio for use cases where you may have a blocking operation (writing to a bounded queue or waiting for a message). Otherwise, use crossbeam.
- wging 4y ago
  I didn't mean to imply these were all substitutes for each other - rather that there are both sync and async channels in the list and it seems worthwhile to compare the sync ones against std::sync::mpsc, and the async ones against tokio::sync::mpsc. Not to mention the sync/async ones against each other (flume and postage both have async capabilities). I do think the site does a decent job of calling out that there is a difference between the two types of channel.

iot_devs 4y ago

I ways wonder what would happen if you were to promise maintenance of those packages and improved doc, and then slap a pricing page for corporate.

woile 4y ago

This is great! I wish it was a bit more opinionated and gave for example 1 or 2 http server option(s). I don't know under which criteria though

nicoburns 4y ago
The options are ordered, so you can effectively get this by just reading the top 2 and ignoring the others. Perhaps this could be made clearer though. I've been trying to balance keeping the list short with providing some context about why you perhaps shouldn't other options.
- woile 4y ago
  I think the approach you've taken by providing this document, allows you to give 1 option, and when there's something better you just change it. Ideally if you follow semver and there's something replacing something else, you could introduce a breaking change. And if you let people navigate different versions, they could see how things changed over time. Thanks for it btw!

pornel 4y ago

I've developed a list of common crates based on the number of active users: https://lib.rs/std https://lib.rs/std

bogeholm 4y ago
And thank you for that! Love lib.rs
CameronNemo 4y ago
How do you determine what an active user is?
- pornel 4y ago
  Roughly that’s number of unique crate owners of reverse dependencies that have been updated within the last couple of years, plus some other factors like downranking crates that lose popularity.
chlorion 4y ago
This is very useful! Thanks for sharing! I've been looking for a list of semi-blessed crates like this for a long time. Before finding this and the OP's site I looked at the dependencies of rustc and cargo and considered those to be mostly trusted.
3a2d29 4y ago
Very cool!

nicoburns 4y ago

This is my project (although I didn't submit this to HN), AMA I consider quite incomplete at this point (but hopefully already useful). There are several categories of crate that just aren't covered yet (suggestions very welcome, either here or on the github repo https://github.com/nicoburns/blessed-rs https://github.com/nicoburns/blessed-rs). I'd also like to add more hand curated content such as: - Installation and developer environment setup - Link to learning resources (books, projects, etc) - Explanations of the community (reddit, TWIR, discourse, github, zulip, etc) - Themed guides (backend web development, CLI tools, game development, etc) I want to put together more guidance on how to contribute, and gradually transition this into more of a community maintained model over time, but I haven't had a chance to do this yet.

outside1234 4y ago
Thanks for putting this together. Some other ideas: * Config: dotenvy * Database: sqlx (async), diesel (sync, ORM) * gRPC: prost (protobuf library)
- TotempaaltJ 4y ago
  Another for config: https://crates.io/crates/config https://crates.io/crates/config
- echelon 4y ago
  +1 for sqlx. Native SQL queries that are typechecked at compile time.
  - maxbond 4y ago
    sqlx is awesome but I'd add the small caveat that it has an annoying sharp edge with sqlite where it relies on sqlite's loose typing, but if you want to use the recent strict feature[1] (which enforces type & check constraints), you need to use the specific underlying types (eg, you need to specify INTEGER, not DATETIME). In which case, I'd recommend the excellent rusqlite. You'll also be able to use all sorts of advanced sqlite features that way, like writing functions in Rust that you can call from your queries[2]. [1] https://www.sqlite.org/stricttables.html https://www.sqlite.org/stricttables.html [2] https://docs.rs/rusqlite/latest/rusqlite/functions/index.html https://docs.rs/rusqlite/latest/rusqlite/functions/index.htm...

mwcampbell 4y ago

> Older binding to the windows APIs. Unofficial, but more complete than windows-rs What is windows-rs missing that's in winapi? So far I've found everything I need in windows-rs, including some pretty obscure corners of the massive Windows API.

bnewbold 4y ago

This seems like a good contribution. It would great if one of these "lists of blessed crates" itself becomes blessed and sticks around! This list seems like it was created by somebody with "good taste", and I enjoy the amount of description. https://lib.rs https://lib.rs has some basic features to make it faster to sniff test various crates. Eg, I like being able to see a summary of the authors, and things like "maintained by RustCrypto team" just looking at the summary. My suspicion is that some concept of graph centrality (perhaps via authors?), and perhaps counting applications which aren't usually distributed via cargo (this contributing to crates.io downloads), could both yield a better popularity metric. But the trend stuff is pretty reasonable already. Some related efforts at documenting pseudo-official crates (in contrast to gigantic "awesome" lists) are the "areweX yet" pages (https://www.arewewebyet.org/ https://www.arewewebyet.org/), the Rust Cookbook (https://rust-lang-nursery.github.io/rust-cookbook/ https://rust-lang-nursery.github.io/rust-cookbook/), and the Rust Lang Nursery (https://github.com/rust-lang-nursery https://github.com/rust-lang-nursery). Here is an ancient github issue from way back in 2014 discussing the idea of "official" crates: https://github.com/rust-lang/cargo/issues/934 https://github.com/rust-lang/cargo/issues/934

tmpfs 4y ago

This is fantastic! My only nitpick would be that the `time` crate is now fully featured and can be a drop in replacement for `chrono`. It also seems to be more actively maintained than `chrono`; i would recommend preferring `time` for new projects. I wish this existed when i was starting out with Rust ;)

pc2g4d 4y ago

Really dig this. Learned some things about my own dependencies!