Recommended Crate Directory
The standard library in Rust is not "batteries included", excluding functionality like HTTP(S),
JSON, timezones, random numbers, and async IO. The recommended crate directory is a hand-curated guide to the
crates.io ecosystem, helping you choose which crates to use.
See also: crates.io (the official crates directory) and
lib.rs (a semi-curated directory).
Common
Very commonly used crates that everyone should know about
General
General purpose
Use Case | Recommended Crates |
---|
Random numbers | rand[docs] De facto standard random number generation library split out from the standard library |
Time & Date | Unfortunately there is no clear answer as to which is best between time and chrono. Evaluate for yourself between these two, but be resassured that both are trusted and well-maintained. time[docs] A smaller, simpler library. Preferrable if covers your needs, but it's quite limited in what it provides. chrono[docs] The most comprehensive and full-featured datetime library, but more complex because of it. |
Regular Expressions | regex[docs] De facto standard regex library. Very fast, but does not support fancier features such as backtracking. fancy-regex[docs] Use if need features such as backtracking which regex doesn't support |
UUIDs | uuid[docs] Implements generating and parsing UUIDs and a number of utility functions |
Temporary files | tempfile[docs] Supports both temporary files and temporary directories |
Gzip (de)compression | flate2[docs] Uses a pure-Rust implementation by default. Use feature flags to opt in to system zlib. |
Insertion-ordered map | indexmap[docs] A HashMap that seperately keeps track of insertion order and allows you to efficiently iterate over its elements in that order |
Stack-allocated arrays | arrayvec[docs] Arrays that are ONLY stack-allocated with fixed capacity smallvec[docs] Arrays that are stack-allocated with fallback to the heap if the fixed stack capacity is exceeded tinyvec[docs] Stack allocated arrays in 100% safe Rust code but requires items to implement the Default trait. |
HTTP Requests | See the HTTP section below for server-side libraries reqwest[docs] Full-fat HTTP client. Can be used in both synchronous and asynchronous code. Requires tokio runtime. ureq[docs] Minimal synchronous HTTP client focussed on simplicity and minimising dependencies. |
Error Handling
Crates for more easily handling errors
Use Case | Recommended Crates |
---|
For applications | anyhow[docs] Provides a boxed error type that can hold any error, and helpers for generating an application-level stack trace. color-eyre[docs] A fork of anyhow that gives you more control over the format of the generated error messages. Recommended if you intend to present error messages to end users. Otherwise anyhow is simpler. |
For libraries | See also: Designing error types in Rust thiserror[docs] Helps with generating boilerplate for enum-style error types. |
Logging
Crates for logging. Note that in general you will need a seperate crate for actually printing/storing the logs
Use Case | Recommended Crates |
---|
Text-based logging | tracing[docs] Tracing is now the go-to crate for logging. log[docs] An older and simpler crate if your needs are simple and you are not using any async code. |
Structured logging | tracing[docs] Tracing is now the go-to crate for logging. slog[docs] Structured logging |
Language Extensions
General purpose utility crates that extend language and/or stdlib functionality.
Serialization
Encode/decode between in-memory representations and general-purpose wire formats
Use Case | Recommended Crates |
---|
General-purpose / format agnostic | serde[docs] De facto standard serialization library. Use in conjunction with sub-crates like `serde_json` for the specific format that you are using (JSON, YAML, etc). Supports a variety of both text and binary protocols, including self-describing ones. |
Non-self-describing, external schema file | prost[docs] Protocol buffer library with strong ergonomics and wide industry adoption. Commonly used with gRPC / `tonic`. Use in conjunction with `protox` to avoid dependency on `protoc`. capnp[docs] Cap'n Proto library. Offers zero-copy usage mode that is optimal for large messages, along with other improvements over Protocol Buffers. Tradeoffs are less wide usage and less developer-friendly. flatbuffers[docs] Flatbuffers library. Also offers zero-copy usage and is more widely used than cap'n proto, with further cost to ergonomics. |
Non-self-describing, no external schema file | postcard[docs]
no_std focused Serde serializer/deserializer, aimed at constrained environments. rkyv[docs] Fast zero-copy deserialization framework that allows arbitrary field types and safe zero-copy mutation. |
System
For low-level interaction with the underling platform / operating system
Use Case | Recommended Crates |
---|
Memory mapping files | memmap2[docs] The older memmap crate is unmaintained. |
Libc | libc[docs] Bindings for directly calling libc functions. |
Windows (OS) | windows[docs] The official Microsoft-provided crate for interacting with windows APIs winapi[docs] Older binding to the windows APIs. Unofficial, but more complete than windows-rs |
*nix (OSs) | rustix[docs] Efficient and safe POSIX / *nix / Winsock syscall-like APIs. It uses idiomatic Rust types: refs, slices, Results instead of raw pointers, safe wrappers around raw file descriptors, bitflags instead of bare integer flags, and several other conveniences. nix[docs] Bindings to the various *nix system functions. (Unix, Linux, MacOS, etc.) |
Math / Scientific
The num crate is trusted and has a variety of numerical functionality that is missing from the standard library.
Use Case | Recommended Crates |
---|
Abstracting over different number types | num-traits[docs] Traits like Number, Add, etc that allow you write functions that are generic over the specific numeric type |
Big Integers | num-bigint[docs] It's not the fastest, but it's part of the trusted num library. rug[docs] LGPL licensed. Wrapper for GMP. Much faster than num-bigint. |
Big Decimals | rust_decimal[docs] The binary representation consists of a 96 bit integer number, a scaling factor used to specify the decimal fraction and a 1 bit sign. |
Sortable Floats | ordered-float[docs] Float types that don't allow NaN and are therefore orderable. You can also use the total_cmp method from the standard library like .sort_by(|a, b| a.total_cmp(&b)) . |
Linear Algebra | nalgebra[docs] General-purpose linear algebra library with transformations and statically-sized or dynamically-sized matrices. However it supports only vectors (1d) and matrices (2d) and not higher-dimensional tensors. ndarray[docs] Less featureful than nalgebra but supports arbitrarily dimensioned arrays |
DataFrames | polars[docs] Similar to the Pandas library in Python but in pure Rust. Uses the Apache Arrow Columnar Format as the memory model. datafusion[docs] Apache DataFusion is an in-memory query engine that uses Apache Arrow as the memory model |
FFI / Interop
Crates that allow Rust to interact with code written in other languages.
Use Case | Recommended Crates |
---|
C | bindgen[docs] Generate Rust bindings to C libraries cbindgen[docs] Generate C bindings to Rust libraries |
C++ | cxx[docs] Safe C++ <-> Rust interop by generating code for both sides. |
Python | pyo3[docs] Supports both calling python code from Rust and exposing Rust code to Python |
Node.js | napi[docs] is a framework for building pre-compiled Node.js addons in Rust. neon[docs] Slower than napi, but also widely used and well-maintained |
Ruby | magnus[docs] Ruby bindings for Rust. Write Ruby extension gems in Rust, or call Ruby from Rust. Supported by Ruby's rubygems and bundler rutie[docs] Supports both embedding Rust into Ruby applications and embedding Ruby into Rust applications |
Objective-C | objc2[docs] Sound and Idiomatic Rust to Objective-C interface and runtime bindings. Main crate in the objc2 project. See also(click to open)objc[docs] Older non-idiomatic bindings crate. Has been superseded by objc2. |
Java/JVM | jni[docs] Implement Java methods for JVM and Android in Rust. Call Java code from Rust. Embed JVM in Rust applications. |
Lua | mlua[docs] Bindings to Lua 5.4, 5.3, 5.2, 5.1 (including LuaJIT) |
Dart/Flutter | flutter_rust_bridge[docs] Works with Dart with or without Flutter |
Erlang/Elixir | rustler[docs] Safe Rust bridge for creating Erlang NIF functions |
Kotlin/Swift/Python/Ruby | uniffi[docs] Share Rust codebase to create cross-platform apps (also 3rd party support for Kotlin Multiplatform, Go, C#, Dart) |
Cryptography
Crates that provide implementations of cryptographic algorithms. This section attempts to list the best crates for the listed algorithms, but does not intend to make recommendations for the algorithms themselves.
Networking
TCP, HTTP, GRPc, etc. And the executors required to do asynchronous networking.
Async Foundations
To do async programming using the async-await in Rust you need a runtime to execute drive your Futures.
Use Case | Recommended Crates |
---|
General Purpose Async Executors | tokio[docs] The oldest async runtime in the Rust ecosystem and still the most widely supported. Recommended for new projects. futures-executor[docs] A minimal executor. In particular, the block_on function is useful if you want to run an async function synchronously in codebase that is mostly synchronous. See also(click to open)async-std[docs] A newer option that is very similar to tokio. Its API more closely mirrors the std library, but it doesn't have as much traction or ecosystem support as Tokio. |
Async Utilities | futures[docs] Utility functions for working with Futures and Streams async-trait[docs] Provides a workaround for the lack of language support for async functions in traits |
io_uring | glommio[docs] Use if you need io_uring support. Still somewhat experimental but rapidly maturing. |
HTTP
HTTP client and server libraries, as well as lower-level building blocks.
Use Case | Recommended Crates |
---|
Types & Interfaces | http[docs] The `http` crate doesn't actually contain an HTTP implementation. Just types and interfaces to help interoperability. |
Low-level HTTP Implementation | hyper[docs] A low-level HTTP implementation (both client and server). Implements HTTP/1, and HTTP/2. Works best with the tokio async runtime, but can support other runtimes. |
HTTP Client | reqwest[docs] Full-fat HTTP client. Can be used in both synchronous and asynchronous code. Requires tokio runtime. ureq[docs] Minimal synchronous HTTP client focussed on simplicity and minimising dependencies. See also(click to open)surf[docs] Client that uses the async-std runtime rather than the tokio runtime. Not well maintained. |
HTTP Server | axum[docs] A minimal and ergonomic framework. An official part of the tokio project. Recommend for most new projects. actix-web[docs] A performance focussed framework. All Rust frameworks are fast, but choose actix-web if you need the absolutely maximum performance. See also(click to open)rocket[docs] Has an excellent API and a solid implementation. However development has been intermittent. poem[docs] Automatically generates OpenAPI definitions. warp[docs] Very similar to axum but with a quirkier API. This is a solid framework, but you should probably prefer Axum unless you particularly like the API tide[docs] Similar to Axum, but based on async-std rather than tokio |
GraphQL Server | async-graphql[docs] A high-performance graphql server library that's fully specification compliant. Integrates with actix-web, axum, poem, rocket, tide, warp. |
Websockets
This section includes libraries for you to use just websockets. However note that many of the HTTP server frameworks in the section above also support websockets
gRPC
Use Case | Recommended Crates |
---|
General Purpose | tonic[docs] gRPC over HTTP/2 with full support for asynchronous code. Works with tokio |
Databases
SQL Databases
The multi-database options (SQLx and Diesel) are generally quite good, and worth considering even if you only need support for a single database.
Use Case | Recommended Crates |
---|
Multi Database | sqlx[docs] Works with Postgres, MySQL, SQLite, and MS SQL. Supports compile time checking of queries. Async: supports both tokio and async-std. |
ORMs | diesel[docs] Has excellent performance and takes an approach of strict compile time guarantees. The main crate is Sync only, but diesel-async provides an async connection implementation. sea-orm[docs] Built on top of sqlx (see above). There is also a related sea-query crate that provides a query builder without full ORM functionality. |
Postgres | tokio-postgres[docs] Postgres-specific library. Performs better than SQLx |
MySQL | mysql_async[docs] Has a poorly designed API. Prefer SQLx or Diesel for MySQL |
SQLite | rusqlite[docs] Provides a sync API to SQLite + provides access to advanced sqlite features. |
MS SQL | tiberius[docs] MS SQL specific library. Has better support for advanced column types than SQLx. |
Oracle | diesel-oci[docs] Diesel backend and connection implementation for oracle databases oracle[docs] Rust bindings to ODPI-C sibyl[docs] An OCI-based interface supporting both blocking (threads) and nonblocking (async) AP |
Utilities
Use Case | Recommended Crates |
---|
Connection pool | deadpool[docs] A dead simple async pool for connections and objects of any type. |
Concurrency
Data Structures
Use Case | Recommended Crates |
---|
Mutex | parking_lot[docs] std::sync::Mutex also works fine. But Parking Lot is faster. |
Atomic pointer swapping | arc-swap[docs] Useful for sharing data that has many readers but few writers |
Concurrent HashMap | See conc-map-bench for comparative benchmarks of concurrent HashMaps. dashmap[docs] The fastest for general purpose workloads papaya[docs] Particularly good for read-heavy workloads. |
Channels | See communicating-between-sync-and-async-code for notes on when to use async-specific channels vs general purpose channels. crossbeam-channel[docs] The same channel algorithm as in the standard library but with a more powerful API, offering a Go-like 'select' feature. flume[docs] Smaller and simpler than crossbeam-channel and almost as fast tokio[docs] Tokio's sync module provides channels for using in async code postage[docs] Channels that integrate nicely with async code, with different options than Tokio |
Parallel computation | rayon[docs] Convert sequential computation into parallel computation with one call - `par_iter` instead of `iter` |
Graphics
GUI
Use Case | Recommended Crates |
---|
GTK | gtk4[docs] Rust bindings to GTK4. These are quite well supported, although you'll often need to use the C documentation. relm4[docs] A higher-level library that sits on top of gtk4-rs |
Web-based GUI | tauri[docs] Electron-like web-based UI. Except it uses system webviews rather than shipping chromium, and non-UI code is written in Rust rather than node.js dioxus[docs] A very nice API layer that has Tauri, Web, and TUI renderers. A native renderer is coming soon. |
Immediate Mode Native GUI | egui[docs] Immediate-mode UI. Lots of widgets. The most useable out of the box if your needs are simple and you don't need to customise of the look and feel |
Retained Mode Native GUI | iced[docs] Retained mode UI with a nice API. It's useable for basic apps, but has a number of missing features including multiple windows, layers, and proper text rendering. floem[docs] Inspired by Xilem, Leptos and rui, floem is currently more complete than any of them for native UI. Used by the Lapce text editor. vizia[docs] Fairly complete with sophisticated layout and text layout, but has yet to make a stable release. See also(click to open)xilem[docs] The replacement for Druid based on the more interoperable Vello and Glazier crates. However, it's currently not complete enough to be usable. freya[docs] Dioxus-based GUI framework using Skia for rendering. slint[docs] Possibly the most complete rust-native UI library. But note that it's dual GPL3/commercial licensed. druid[docs] Druid is a relatively mature alternative to Iced/Slint, however it has been discontinued in favour of Xilem so it's use for new projects is discouraged. gpui[docs] High performance framework used in the Zed text editor. Now available on macOS and linux. makepad Makepad has a strong focus on performance and minimising bloat but is consequently less feature complete in areas such as accessibility and system integration. ribir[docs]
cushy[docs]
rui[docs]
concoct[docs]
kas[docs]
|
Window creation | winit[docs] The defacto standard option. Uses an event loop based architecture. Widely used and should probably be the default choice. tao[docs] A fork of winit by the Tauri project which adds support for things like system menus that desktop apps need. baseview Specialized window creation library targetting windows to be embedded in other applications (e.g. DAW plugins) |
2D Renderers | femtovg[docs] OpenGL based. Offers a simple API. Probably the easiest to get started with. skia-safe[docs] Bindings to the Skia C++ library. The most complete option with excellent performance. However, it can be difficult to get it to compile. vello[docs] WGPU based and uses cutting edge techniques to render vector paths using the GPU. Still somewhat immature and hasn't yet put out a stable release. vger[docs] A simpler WGPU based option which is less innovative but currently more stable than vello. webrender[docs] OpenGL based. Mature with production usage in Firefox but documentation and OSS maintenance are lacking. |
UI layout | taffy[docs] Supports Flexbox and CSS Grid algorithms. morphorm[docs] Implements it's own layout algorithm based on Subform layout |
Text layout | cosmic-text[docs] Full text layout including rich text and support for BiDi and non-latin scripts. The best option for now. parley[docs] Another very accomplished text layout library used by Druid/Xilem. |
Accessibility | accesskit[docs] Allows you to export a semantic tree representing your UI to make accessible to screen readers and other assistive technologies |
Clipboard | arboard[docs] A fork of rust-clipboard that supports copy and pasting of both text and images on Linux (X11/Wayland), MacOS and Windows. |
File Dialogs | rfd[docs] Platform-native open/save file dialogs. Can be used in conjunction with other UI libraries. |
Game Development
Use Case | Recommended Crates |
---|
Game Engines | bevy[docs] An ECS based game engine, good for 3D but also capable of 2D. fyrox[docs] An OOP-focused game engine with 3D and 2D support and a full GUI scene editor. ggez[docs] A simpler option for 2d games only. macroquad[docs] A simple and easy to use 2d game library, great for beginners. |
3D Math | glam[docs] Fast math library optimised for game development use cases |