[HN Gopher] Blessed.rs - An unofficial guide to the Rust ecosystem
___________________________________________________________________
Blessed.rs - An unofficial guide to the Rust ecosystem
Author : andrewshadura
Score : 224 points
Date : 2022-11-07 14:25 UTC (8 hours ago)
(HTM) web link (blessed.rs)
(TXT) w3m dump (blessed.rs)
| kjaleshire wrote:
| 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
|
| [1] https://internals.rust-lang.org/t/follow-up-the-rust-
| platfor...
| iot_devs wrote:
| 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.
| GolDDranks wrote:
| Some more I'd wish to see on the page:
|
| - slotmap
|
| - memchr
|
| - bytecount
|
| - rouille
|
| - csv
| maxbond wrote:
| Submit a PR or open an issue!
|
| https://github.com/nicoburns/blessed-rs
| epage wrote:
| Doesn't bstr replace memchr? Unsure if it replaces bytecount.
| burntsushi wrote:
| 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.
| pornel wrote:
| I've developed a list of common crates based on the number of
| active users:
|
| https://lib.rs/std
| bogeholm wrote:
| And thank you for that! Love lib.rs
| gavinray wrote:
| 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/DataDog/glommio/issues/554
| nicoburns wrote:
| 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).
|
| 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 wrote:
| Thanks for putting this together.
|
| Some other ideas:
|
| * Config: dotenvy
|
| * Database: sqlx (async), diesel (sync, ORM)
|
| * gRPC: prost (protobuf library)
| TotempaaltJ wrote:
| Another for config: https://crates.io/crates/config
| rob74 wrote:
| Thanks for compiling this! One small nitpick: "De facto random
| number generation library" doesn't mean what you probably want
| to say, it should be "De facto _standard_ [...] library ".
| Otherwise the "de facto" applies to "library", and that doesn't
| really make sense (at least not in Rust, where it's very well
| defined what can be called a library and what not)...
| c0balt wrote:
| Just a small suggestion might be the category templating
| engines (incomplete list, based on my experience):
|
| - askama
|
| - tera
|
| - liquid
|
| And more importantly logging, due to this being a common
| usecase:
|
| - log
|
| - ... and companions
|
| - (maybe even advanced things, like opentelemetry)
| rob74 wrote:
| OTOH, this is supposed to be a list of "de facto standard"
| libraries. If there are several alternatives with no clear
| "winner", that may not be a good fit for this list?
| mrits wrote:
| 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
| endorphine wrote:
| 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.
| stusmall wrote:
| For me I always point to the Java's time library pre-8 as an
| example. It was a common pain point, experienced Java devs
| would know to use joda time but beginners wouldn't know to look
| to an alternative to the one in the standard library
| implementation. Over many years and a lot of pain, it was
| eventually replaced.
|
| If libraries are initially kept outside of the standard library
| they can compete, gain and lose support, and a clear winner
| will eventually surface. Old patterns can continue to exist and
| be support without breaking changes while new, better APIs can
| incubate. In time, after they've proved themselves, then they
| can be pulled into the stdlib.
|
| When it isn't included in the stdlib then a new developer needs
| to always ask "is this the recommended library?" In some of my
| projects I'm still using a few libraries that might not be the
| preferred community solution anymore, they are still very well
| supported. When a winner becomes more clear then I can migrate.
|
| It comes down to two different approaches. Both are valid, both
| have their advantages. I prefer rust's conservative approach to
| the stdlib but I understand why someone would rather less
| reliance on shifting 3rd party libraries.
| brundolf wrote:
| Some people would say Rust has too many batteries included in
| the standard library (even though no_std exists)
|
| "Not enough" or "too much" is relative to your use-case. Go is
| almost purpose-built for web servers, whereas Rust is much more
| general and lower-level. It's got excellent built-ins for core
| data structures, async primitives, etc (which makes it much
| more batteries-included than C), but many (most?) of Rust's
| users don't need an HTTP server or JSON parsing
|
| It's a judgement call. I think they struck a reasonably good
| balance, especially considering the vibrant ecosystem and
| breezy package management that can help fill in the gaps, but
| it's never going to be perfect
| maxbond wrote:
| Both are legitimate approaches with interesting tradeoffs, and
| Rust and Go are both great languages with distinct strengths.
| There's a sort of cathedral and bizarre dynamic at work. Go's
| language design decisions feel like a bizarre where people just
| kinda brought their ideas and they happened; think about the
| way you format dates in Go, it feels very much like someone
| just thought that up, was like "yeah that feels right", and
| shipped it. Their standard library is more of a cathedral; it's
| expansive, monolithic, and complete.
|
| Rust's language design decisions are more of a cathedral; the
| language feels cohesive and carefully put together, like a
| delicate puzzle. They're slow to adopt language design
| decisions, leaving them in an unstabilized purgatory until a
| very high degree of confidence is developed that it's the right
| decision. Rust's approach to dependencies is more of a bizarre;
| you're expected to go to crates.io and work out what
| dependencies to adopt for just about everything.
| rapsey wrote:
| 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.
| kibwen wrote:
| Rust's standard Mutex type has been improved to the point
| that they're now competitive or faster than parking_lot, at
| least on Linux: https://github.com/rust-
| lang/rust/pull/95035#issuecomment-10...
|
| Channels appear to be trickier, but it might be possible to
| upstream crossbeam's version of those as well (it's certainly
| been proposed and discussed for years).
| maxbond wrote:
| 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
|
| 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.
| ohbtvz wrote:
| > Because it requires that library with that API be
| maintained forever.
|
| Why would you say that? Do a cycle of deprecate + remove
| every few major releases, provide a migration path, and
| you're good.
| pornel wrote:
| No, Rust has a strong backwards compatibility guarantee. It
| can deprecate stuff, but not remove.
|
| Editions currently don't allow existence of multiple
| standard libraries, because code from different editions
| can be mixed.
| kibwen wrote:
| Note that editions don't allow multiple standard
| libraries, but it would be possible (trivial, even) to
| use an edition-specific lint to deny access to a
| deprecated function on a newer edition. Even with that,
| editions don't allow you to expose two different symbols
| with the same name from the one single libstd so you
| can't easily "reclaim" or "redefine" an existing
| function, however since Rust already does mangling it
| should be possible (though potentially hairy) to expose
| identically-named functions that resolve to different
| symbols depending on the chosen edition of the crate.
|
| Neither of these things have ever been done, though they
| have been proposed, and it's just up to the library team
| to determine if they ever think it would be worth it to
| do so.
| nicoburns wrote:
| I would absolutely love rustc to gain the ability to
| rename stdlib types across edition boundaries (e.g. you
| create a Range2 type which is named Range in Rust 2024,
| or vice versa). I'm not super familiar with the compiler
| internals, but it seems to me that it shouldn't be all
| that hairy. One ought to be able to deal with this in a
| single pass at a very early stage in the compile process.
|
| Seems like this would be a great way to deal with
| deprecated stdlib functionality. Especially in the case
| that there is a better replacement available. Ranges and
| channels would be obvious candidates for this.
| endorphine wrote:
| With things that don't change often like JSON, XML and
| crypto, the same argument doesn't hold much value though.
| maxbond wrote:
| Those are all use cases that are likely to have security
| issues; it would be nice if we could release security fixes
| for them without needing to bump up the release schedule of
| the entire language. (But this is an area where good
| engineers reasonably differ.)
| fiedzia wrote:
| crypto does change. Maybe not specifications of specific
| algorithms, but which of them are supported may change. Do
| we want to break existing code when one of them will become
| deprecated or do we want to allow insecure method to be
| used to make web requests?
| cesarb wrote:
| > > With things that don't change often like [...] and
| crypto
|
| > crypto does change
|
| A nearby comment mentioned Python, which did have that
| problem. The ssl module on its standard library didn't
| verify certificates by default, and since that's no
| longer considered good cryptographic practice (to put it
| mildly), that behavior had to change, even though it
| could break existing code. See for instance
| https://access.redhat.com/articles/2039753 and the
| several PEPs it links to, in particular
| https://peps.python.org/pep-0466/ which is about the
| backporting of the Python 3.x version of that module to a
| _patch release_ of Python 2.7.
| nequo wrote:
| I think the idea is that the people who write the compiler
| might be good at writing compilers but less good at designing
| HTTP or crypto libraries. So they leave that work to others.
|
| Designing Cargo was outsourced for a similar reason AFAIK.
| kibwen wrote:
| Yes, back in the day the goal was to provide a "batteries
| included" stdlib with Rust, but eventually it became obvious
| that good library design was hard and so almost all of the
| "batteries" (like rand, rustc_serialize, many of the
| collections, datetime, and more) were all offloaded to
| crates.io.
|
| As for cargo, what we have today is literally Rust's third
| package manager, after the experience with using the first
| two led people to conclude that they just needed to hire
| domain experts to design and implement it (the bundler
| folks).
| alfiedotwtf wrote:
| Perl has BerkeleyDB and CGI in core. Peripheral library tastes
| change over time, core backward compatibility lasts a lifetime
| pornel wrote:
| * Rust competes with C that comes with a leaking lead-acid
| battery, so Rust's standard library already seems large and
| luxurious in comparison.
|
| * One size does not fit all. Rust targets many different
| environments, including embedded and WASM. A big stdlib makes
| porting Rust harder. It's already problematic, e.g. `std::fs`
| makes no sense in a browser context, and std's out-of-memory
| handling strategy was unacceptable for the Linux kernel.
|
| * Rust is judged by the size of its "Hello World!" executable,
| which already looks pretty fat due having stdlib linked
| statically.
|
| * Rust has a strong backwards-compatibility guarantee, which
| means that anything stabilized in stdlib has to stay, forever,
| and can't evolve. Not many features can be nailed on the first
| try, and not nailing them means people will forever debate
| whether to use the worse-but-standard version or a 3rd party
| version.
|
| * Rust has already dodged some bullets, because 3rd party
| `serde` turned out better than Rust's old built-in `rustc-
| serialize`, `syn` won over Rust's `syntex`, `criterion` is
| better than built-in `bencher`, `rand` had 8 major revisions,
| `time` broke compat 3 times, etc.
|
| * Rust is stuck with `std::mpsc` which turned out to be slower
| and less flexible than `crossbeam-channel`.
|
| * Rust team is not an infinite resource.
|
| * The Rust language is designed to be extensible via libraries,
| unlike Go where e.g. maps, channels, range iteration are
| special built-ins you can't replace.
| Sphax wrote:
| 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__ wrote:
| Maybe, both are okay and it's just a matter of taste?
| conradludgate wrote:
| 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 wrote:
| 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.)
| Sphax wrote:
| Thanks for the information. If both are now maintained I'll
| probably just try both crate and see which one I prefer.
| nicoburns wrote:
| 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?
| woile wrote:
| 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 wrote:
| 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 wrote:
| 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!
| freedomben wrote:
| 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 wrote:
| 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. 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 wrote:
| 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?
| fiedzia wrote:
| > do you use Rust for (nearly) everything?
|
| Nearly. There are still some things easier to do in Python or
| JS, but the gap is closing quickly and I'm fine with spending
| small amount of convenience to get quality of Rust code. I am
| looking now into having nearly 100% Rust frontend + Rust
| backend for some simple project and it does look promising.
| SevenNation wrote:
| The most surprising thing about Rust is how high-level it feels
| compared to other "systems" languages. Unless the problem space
| _demands_ something other than Rust, I don 't see much reason
| to choose anything else. And this includes projects where Ruby,
| Python, and JavaScript were used.
| quake wrote:
| 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.
| ReadEvalPost wrote:
| Do you have any recommendations on libraries for parsing CAN
| with Rust (or are your tools OSS)? I'll be working on a
| project in a couple of months that'll need to pull data off
| CAN.
| [deleted]
| rapsey wrote:
| > I did C/C++ for years 10+ years ago, but since learning Ruby
| and then Elixir I've loved the functional approach.
|
| Not Elixir but I spend 10 years in Erlang before moving to Rust
| and prefer to never go back.
|
| A statically typed language is just better. No matter how easy
| Erlang/Elixir makes some things. I do not at all miss needing
| to refactor my code and being scared of all the crashes that
| inevitably result. I do not at all miss seeing crashes that
| only show up under production load.
| freedomben wrote:
| Thanks, that is pretty helpful since Erlang and Elixir are so
| similar in philosophy.
|
| How long did it take you to get to the point with Rust where
| you wouldn't want to back?
|
| Do you use any sort of actor implementation in Rust?
| lalaithion wrote:
| It's very general purpose. I feel like I could do anything in
| it. However, I still do numerical stuff and one-off scripts in
| Python, just due to lack of friction and not needing
| correctness/performance, and for bigger projects where being
| I/O bound is the main issue - I still use Rust, but I do wish
| there was an alternative which was "Rust but with a garbage
| collector".
|
| Haskell and the ML family are fine but they just don't have the
| same number of high-quality libraries with the well thought out
| modern stdlib of Rust as a base. Elixir/Erlang/Lisps are fine
| but I'd really like strong, static types. Gleam/Pony are too
| niche. I'd like to like Scala but every time I try I run into
| something inscrutable and demonic, and the Java ecosystem is
| comprehensive but (in my opinion) super annoying.
| LinXitoW wrote:
| Damn do I with there was Rust with GC. Rust has so many
| wonderful high level features I'm missing even in "hip"
| languages (compare error handling with Kotlin), but I don't
| really care that much about the systems programming parts.
| pizza234 wrote:
| > Does anybody else have a similar background that can share
| their opinion/love level of rust?
|
| I come from higher level language(s). But I find hard to
| program without functional composition as well.
|
| > 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?
|
| General purpose language != efficient for all the use cases. I
| do a considerable amount of hobby programming in Rust, but I
| think it's a niche language. I think it's vastly most efficient
| to use other language in the very large majority of the use
| cases - there are plenty of modern languages the are good
| enough and don't have such a high overhead (ie. manual memory
| management). Nonetheless I've found that with a couple of years
| of experience (likely less than half, if programming
| professionally), developing with Rust is considerably simpler
| than one would imagine.
| marcus_cemes wrote:
| I've done some C/C++, a lot of JS/TS due to its web dominance.
| I found Elixir a year ago and fell in love with it.
|
| I love the functional style of Elixir, it's elegant to write
| and read, but feels unsafe. The lack of a type system is hard
| for me and has been a nightmare when trying to find the origin
| of a particular error tuple and refactoring code, running the
| app to see if it works. Running it in production feels like a
| ticking time bomb, even if it does handle fault tolerance
| gracefully.
|
| I've reached for Rust for the occasional project and have never
| regretted it, I couldn't justify its use for everything though.
| Very high-quality ecosystem, rock solid and predictable
| performance and tiny footprint. I've made a VPN supervisor
| process that fits in a few MB Docker image (without OS), uses a
| few MB of RAM, no idle CPU and wonderful latency.
|
| Perhaps Erlang can manage tail latencies better under load,
| pre-emptive scheduling is awesome, but my personal experience
| has been that Rust is just much more efficient at doing the
| same task, giving you more free CPU time, predictable memory
| freeing that rivals Erlang's per-process GC. You finish that
| blocking computation before it even becomes noticeable.
| Erlang's fault tolerance is matched by Rust's type system and
| memory safety guarantees. It's hard to compare C++/Rust to
| Erlang/Python/Ruby, they're just different.
|
| It's slower and more frustrating to write, but the language
| server gives you so much feedback and useful comments. I find
| the linter amazing, it finds some pretty obscure and neat
| improvements with the additional type information it has, and
| Option<T> and Result<T,E> have an almost functional-like
| chaining pattern.
|
| For a small hobby project, Rust 100% of the time. No painful
| dependency management, no complex build process. For a more
| serious project, or for a client, not always justifiable. I
| always miss Rust's language features and libraries when coding
| in another language that has the upper hand in their respective
| dominant fields, although I like that a lot of tooling
| (ESBuild, swc, Tailwind's compiler, fnm, Rome, ...) is being
| remade in Go/Rust, it benefits far more people than it
| inconveniences.
| papascrubs wrote:
| 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.
| jmfurlott wrote:
| Curious about one for python as well
| dimitar wrote:
| The clojure toolbox: https://www.clojure-toolbox.com/
|
| There also the various awesome lists on GitHub, but they are
| not always well curated
| kibwen wrote:
| Note that they're literally called "Awesome" lists, that's
| not an adjective describing the lists themselves. :P
| wging wrote:
| 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 wrote:
| 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 wrote:
| 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.
| root_axis wrote:
| 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 wrote:
| 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 wrote:
| Thanks!
| mwcampbell wrote:
| > 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.
| lijogdfljk wrote:
| Tangent, i really enjoy the design of that site. Crisp, readable,
| simple. Maybe a bit low on contrast, but not terribly so.
| mpalmer wrote:
| Agreed; I'd give it full marks if it were optimized for mobile.
| nicoburns wrote:
| I've added some basic mobile styling :) Probably could be
| better, but I think this makes it somewhat readable on
| mobile.
| kitd wrote:
| 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 wrote:
| 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!
| echelon wrote:
| See also:
|
| 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).
| tptacek wrote:
| 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.
| Xeoncross wrote:
| 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 wrote:
| 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
| jaxrtech wrote:
| 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 definitely helps as well.
___________________________________________________________________
(page generated 2022-11-07 23:00 UTC)