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.
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)...
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?
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].
Thank you, this will help me a lot. I'm playing around a bit with Rust and knowing which libraries are popular and therefore somewhat trustworthy and dependable is really important. Your list is a nice collection and lists many of the things I've come across and played with, but there are some new ones which I didn't know existed and which I know will come in handy at some point.
I think [slotmap](https://docs.rs/slotmap/latest/slotmap/) could be on there somewhere, I have found it very useful for various projects. I guess it could be listed under datastructures?
I’ve been interested in dabbling with Rust for some time but haven’t really had an idea of where to start or what to use if I do - this is super helpful in a way that the Awesome ** pages just aren’t bc of the info it gives on each library. Nice initiative - thanks for putting it together.
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 ?
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.)
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?
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.
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.
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.)
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.
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.
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.
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.
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.
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).
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.
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.
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
• 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.
The only other thing I'd add to this list is that Cargo and crates.io predate Rust 1.0, and that (subjectively) Cargo is an excellent package manager. So taking a dependency on 3rd party crates has always been simple and consistent in Rust, and the marginal added convenience of having something in the stdlib is smaller than in most other languages. In contrast, the Go tooling leaned pretty heavily towards monorepos and vendoring for several years, before the standardization of go.mod.
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.
The other side of the coin: Java had, with java.util.Date/Calendar, the basics on board. If your project grew enough to need more than the absolute basic date handling, adding Joda was easy enough. Even so, the Date class provided enough of a lingua franca that other libraries could provide dates and times to their vallers without depending on Joda.
Compare it with Java's logging framework hell. java.util.Logging used to be near-unusable, and the resulting cambrian explosion of logger frameworks continues to this day. Using a library will make you depend on some logging framework. So it is today normal for a Java program to contain 4-5 different logging frameworks, passing messages to each other.
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 pretty 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 for everybody's usecase
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.
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.
Python deprecates stuff all the time. I got bit by this just last week when dusting off some old code and trying to update it from 3.7 only to find out that it's broken because stuff got moved around and now some imports don't work.
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.
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.
If Rust added support for that operating system, than all of the packages that didn't rely on platform specific features would work (which is to say, virtually all of them). As it is, I'd speculate that with some fiddling you could probably get them working there today, but you'd have to repeat that every time you wanted to move to a new version of Rust. That isn't really a function of whether or not the language is batteries included, and making it batteries not included can make porting the language to new platforms simpler.
But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
I've not had the experience that Rust libraries rely on platform specific behavior (ignoring things that specifically expose the capabilities of a platform specific like a HAL crate or an io_uring crate). I've had far less trouble than I anticipated getting up and running in embedded and WASM contexts.
Have you had a different experience that's leading you to these views?
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).
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.
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.
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.)
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?
> > 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.
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.
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).
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.
It's on a take it or leave it basis, I try not spend too long on a comment. Some of them come out well and some don't. I thought there was something interesting enough there to share; if you didn't get anything out of it, my apologies, but I'm moving on.
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 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.
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
> 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.
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.
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.
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.
> 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).
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.
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.
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?
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.
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.
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.
> 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.
Well I had a major project for which Rust was the only logical choice. I very quickly found Rust to just be very enjoyable to use. So even if something is in the Eralng/Elixir wheelhouse I would still prefer Rust.
I do not use an actor framework. It is best to use whatever is standard for the language. For Rust this is Tokio async ecosystem.
> 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.
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.
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.
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.
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.
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.
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.