actix

Actix implements the actor model for Rust: independent units of state and behavior that communicate exclusively through typed, asynchronous messages instead of shared memory. Each actor runs inside its own Context, is addressed through an Addr or Recipient handle, and processes incoming messages one at a time, which removes a large class of data-race and locking bugs from concurrent application code.

Built on top of the Tokio runtime via actix-rt, Actix supports both async and sync actors, actor supervision and restart semantics through Supervisor, and service lookup through Registry/SystemRegistry. The companion actix-derive crate supplies #[derive(Message)] and #[actix::main] macros that remove most of the boilerplate around defining and dispatching messages.

Actix predates and underlies the better-known actix-web framework, but the actor crate itself is a general-purpose concurrency primitive — useful anywhere an application needs isolated, supervised, message-passing components rather than a web server, such as background workers, connection managers, or stateful protocol handlers.

What You Get

• The Actor trait plus Context<A> for defining actors with started/stopping/stopped lifecycle hooks
• Typed messaging via the Message trait and Handler<M>, with Addr and Recipient for sending messages to actors you own or only need to notify
• Supervisor for restarting actors that fail, and Registry/SystemRegistry for locating shared actor-backed services
• SyncArbiter/SyncContext for running CPU-bound actor work on a dedicated thread pool alongside the async event loop
• #[derive(Message)] and #[actix::main] macros (via actix-derive) that eliminate most message and startup boilerplate
• StreamHandler and ActorFuture/ActorStream combinators for wiring async streams and futures directly into an actor’s execution context

Common Use Cases

• Modeling stateful background workers (queue consumers, connection pools, session managers) as isolated, restartable actors
• Building the concurrency core for a larger networked service, including actix-web, which is built directly on top of this crate
• Coordinating multiple long-lived tasks that need to exchange typed messages without exposing shared mutable state or manual locking
• Implementing supervised, fault-tolerant components where a crashed actor should be automatically restarted rather than taking down the process
• Bridging synchronous, CPU-bound work into an async application via SyncArbiter without blocking the main event loop

Under The Hood

Architecture Actix is organized as a Cargo workspace of three crates — actix (the core), actix-derive (proc macros), and actix-broker (a pub/sub layer built on top) — with the core crate itself layered into distinct concerns: actor definition and lifecycle (actor.rs, handler.rs), execution context (context.rs, context_impl.rs, context_items.rs), addressing (address/ with dedicated channel.rs, envelope.rs, message.rs, and queue.rs submodules), and supervision/service-lookup (supervisor.rs, registry.rs). Every actor runs inside a Context<A> bound to an Arbiter, and all cross-actor communication is routed through the address module’s mailbox/envelope machinery rather than direct method calls, so changing the message-passing layer would ripple through nearly every other module. This is a solid, purpose-built layering for the actor model rather than a generic application framework.

Tech Stack The core crate is pure Rust built on actix-rt (Actix’s Tokio-based runtime wrapper), with futures-core/futures-sink/futures-task/futures-util for the futures ecosystem, tokio and tokio-util (codec feature) for I/O and stream framing, crossbeam-channel and parking_lot for low-level concurrency primitives, and bitflags, bytes, smallvec, pin-project-lite, and once_cell rounding out the dependency set. CI runs the full matrix (Linux, macOS, Windows) against both the tracked MSRV and stable Rust, with separate clippy/fmt and coverage workflows enforcing lint and format hygiene on every change.

Code Quality The crate ships an extensive dedicated test suite — one file per subsystem (test_actor.rs, test_address.rs, test_arbiter.rs, test_context.rs, test_lifecycle.rs, test_supervisor.rs, test_sync.rs, and more) plus derive-macro tests, all exercised across three OS targets and both MSRV and stable Rust in CI. lib.rs enables #![deny(rust_2018_idioms, nonstandard_style, future_incompatible)], and a standalone clippy/fmt workflow runs on every PR, giving the project consistent lint and style enforcement on top of its test coverage.

API Design Actix favors compile-time-checked, typed messages over stringly-typed or dynamically-dispatched alternatives: #[derive(Message)] with an #[rtype(...)] attribute declares a message’s response type once, and Handler<M>::handle is then statically checked against it, so mismatched message/response pairs are caught at compile time rather than at runtime. Addr and Recipient provide two levels of coupling (owning the full actor’s message set vs. a single message type), and #[actix::main] collapses application startup into a single attribute. The tradeoff is a real conceptual learning curve — the actor model, arbiters, and context lifecycle are unfamiliar to developers coming from typical async/await Rust code — but the resulting API surface is small, consistent, and well-documented for what it does.