# Actix: the actor crate behind the Actix name, and how to tell it apart from Actix Web

> Actix is the actor framework crate in the actix/actix workspace, not the web framework. Here is what it does, how to install and run a first actor, and where it stops being the right choice.

**actix/actix** — Actor framework for Rust.

- Repository: https://github.com/actix/actix
- Stars: 9,250 · Forks: 676
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/actix-actix

## Actix is the actor crate, Actix Web is a different project

The single most common source of confusion around this name is that two things share it. actix/actix is an actor framework for Rust: it gives you actors, typed messages, addresses and supervision. Actix Web, the HTTP framework, is a separate crate and a separate repository that builds on the same runtime stack. The README for this repository says exactly that and nothing more: "Actor framework for Rust". It points readers to a user guide at actix.rs/docs/actix and API documentation at docs.rs/actix.

So the audience here is narrow. If you are choosing an HTTP framework, this repository is not the thing you install. If you have an in-process concurrency problem where shared mutable state behind a mutex has become the design, this is the crate that gives you a different shape: state lives inside an actor, and the only way to touch it is to send a message. The README lists the intended capabilities plainly: async and sync actors, actor communication in a local or thread context, futures for asynchronous message handling, actor supervision, and typed messages with no Any type.

That last point matters more than it reads. Messages are typed at compile time through the Message trait and its rtype attribute, so a handler's return type is part of the type system rather than a downcast at runtime. The cost is boilerplate: every message is a struct, every response type is declared, and every handler is an impl block.

## How the message flow actually works: System, Actor, Addr, Recipient

The mechanism is visible in the README's examples. Everything starts with a System, which the README describes as creating a new event loop. Actix uses the Tokio runtime, and System::new() creates that event loop while System::run() starts it. The system finishes when the System actor receives a SystemExit message.

An actor is a struct that implements the Actor trait. The associated type Context<Self> decides how the actor is scheduled; the README's examples use Context<Self> throughout. The trait also exposes lifecycle hooks. The README names started, stopping and stopped, with started called when the actor starts and stopping when it finishes.

Communication goes through an Addr. The README is explicit: all communications with actors go through an Addr object. From an Addr you can do_send a message without waiting for a response, or send a message and receive a future for the result. The Message trait declares the result type, and a Handler implementation on the actor supplies the code that runs.

Recipient is the looser handle. Where Addr is tied to a concrete actor type, Recipient<Ping> lets an actor hold a handle to anything that can handle that message type. The README's second example uses Recipient to wire two actors into a cycle, and it needs Game::create with a closure rather than start, because the actor must obtain its own address before it finishes constructing. That detail is the real shape of the API: circular actor graphs are possible but require the create constructor and a closure that receives the context.

## Installing actix and running a first calculator actor

The README gives the dependency line directly. Add actix to Cargo.toml:

```toml
[dependencies]
actix = "0.13"
```

The README also states the minimum supported Rust version: stable Rust 1.88 or newer. The workspace Cargo.toml agrees, setting rust-version = "1.88" and edition = "2021". Build with a toolchain that satisfies that, or cargo will refuse the crate.

The shortest working program in the README defines a message, an actor, and a handler, then uses the #[actix::main] attribute so the main function can await a response. The attribute starts the system and blocks until the future resolves, which removes the manual System::new() and system.run() dance for simple cases.

```rust
use actix::prelude::*;

#[derive(Message)]
#[rtype(usize)]
struct Sum(usize, usize);

struct Calculator;

impl Actor for Calculator {
    type Context = Context<Self>;
}

impl Handler<Sum> for Calculator {
    type Result = usize;

    fn handle(&mut self, msg: Sum, _ctx: &mut Context<Self>) -> Self::Result {
        msg.0 + msg.1
    }
}
```

With that in place, the main function starts the actor and sends it a message, awaiting the reply. The README's version prints SUM: 15 for Sum(10, 5) and prints a failure line if the send does not resolve to Ok.

```rust
#[actix::main]
async fn main() {
    let addr = Calculator.start();
    let res = addr.send(Sum(10, 5)).await;

    match res {
        Ok(result) => println!("SUM: {}", result),
        _ => println!("Communication to the actor has failed"),
    }
}
```

If you prefer the explicit form, the README's first example builds the system by hand with System::new(), starts the actor inside system.block_on, and then calls system.run(). Either path works; the attribute is the shorter one.

## Where actix stops being the right tool

The first limitation is the one the naming creates. If your problem is HTTP routing, request extraction, middleware and response building, actix is the wrong crate. It has no router and no HTTP server in it. The README's own pointer to a chat example shows the intended scale: a program made of actors exchanging messages, not a web service.

The second is that typed messages cost you flexibility. Because Message and Handler are generic over the message type, adding a new interaction means adding a new struct and a new impl. A design that would be one function call in a shared-state program becomes a message type, a handler and an address to keep. The README frames the trade-off positively ("No Any type"), and the compile-time safety is real, but the boilerplate is the price and it does not shrink as the actor count grows.

The third is lifecycle complexity in graphs. The cyclic example in the README needs Game::create with a closure specifically so each actor can hand its Recipient to the other before it starts. That is a real constraint of the API, not an accident of the example: if actors must reference each other, you cannot simply call start on both and wire them afterwards. The README does not document rollback, migration or shutdown ordering beyond naming the SystemExit message and the stopping and stopped hooks.

Finally, the documentation is thin on operational questions. The README covers the API surface; it does not discuss failure recovery policy, mailbox sizing or backpressure. Supervision is listed as a feature, and the user guide is where the README sends you for anything deeper. Treat that as the boundary of what this repository tells you.

## Actix versus Tokio tasks, and the Axum question

The most direct alternative is not another actor framework but Tokio itself. Actix already runs on Tokio, so the comparison is about shape rather than runtime. With Tokio you spawn tasks and share state through channels, mutexes or Arc; the concurrency model is explicit in your own code. With actix you get an actor abstraction on top: state is owned by the actor, mutation happens inside handlers, and the address is the interface. If your state is naturally a single owner with a message protocol, actix removes the locking question. If your work is a pipeline of independent tasks, plain Tokio is less machinery.

The other comparison people reach for is Axum, and the honest answer is that they are not substitutes. Axum is a web framework; actix is an actor framework. The overlap is only that both sit on the Tokio ecosystem. Choosing between them is really choosing whether you are building an HTTP service or an in-process concurrent system. The README points at a chat example for "more comprehensive usage", which is a reasonable hint that the intended use case is a stateful, message-driven program rather than a request/response server.

## Maintenance, versioning and the licence split

The repository is not archived, and the last push was on 2026-09-14. The release history is uneven across the three crates in the workspace. actix-broker reached v0.4.4 on 2025-06-12, actix_derive reached v0.6.2 on 2024-09-12, and actix itself reached v0.13.5 on 2024-06-09. The README's dependency example pins actix = "0.13", which matches that latest published actix release. The workspace members are actix, actix-broker and actix-derive, so a change to the derive macro or the broker can land without a matching actix release.

On licensing, the picture is split and worth reading carefully. The repository's Cargo.toml declares the workspace package licence as "MIT OR Apache-2.0", and the top-level files include both LICENSE-APACHE and LICENSE-MIT. The repository metadata, however, lists Apache-2.0. If your policy depends on which of the two you are accepting, check the licence files in the crate you actually depend on rather than the repository summary. This is a description of what the files say, not legal advice.

Upgrade cost is mostly the MSRV. The workspace sets rust-version = "1.88", and the justfile contains a downgrade-for-msrv recipe that pins several dev-dependencies (actix-web, actix-http, half, idna_adapter, litemap, zerofrom) to versions that still build on the minimum toolchain. That recipe exists because the dependency tree otherwise outruns the declared MSRV. If you track the crate, expect that constraint to move before the API does.

## Conclusion

Adopt actix when you want typed, message-passing concurrency inside a Rust process and are willing to design around Addr, Recipient and supervision. Do not adopt it as a web framework, and do not adopt it if your workload is request/response HTTP, where a router plus async handlers is simpler. Before committing, verify two things in the actix/actix repository itself: whether the actor crate's 0.13 line is where your code will live, and whether your toolchain satisfies rust-version = 1.88, since the workspace declares that MSRV and the justfile's test-msrv recipe downgrades several dev-dependencies to keep it working.

## FAQ

### What is the difference between actix and Actix Web?

actix is the actor framework crate in this repository; Actix Web is the separate HTTP framework that shares the name. The README describes this repository only as an actor framework and links to a user guide and API docs, with no router or HTTP server in the crate.

### What is actix in Rust?

It is an actor framework for Rust that provides async and sync actors, typed messages, actor communication in a local or thread context, supervision, and a System that runs on the Tokio runtime. The README states it runs on stable Rust 1.88 or newer.

### How do I install actix?

Add the dependency to Cargo.toml as actix = "0.13", which is the line the README gives, then build with a toolchain of Rust 1.88 or newer. Creating a System and implementing the Actor trait are the next steps the README shows.

### Is actix still maintained?

The repository is not archived, and the last push was on 2026-09-14. Release timing differs by crate: actix-broker v0.4.4 on 2025-06-12, actix_derive v0.6.2 on 2024-09-12, and actix v0.13.5 on 2024-06-09.

### Is actix faster than Axum?

This repository does not make that comparison, and the two are not the same kind of crate: actix is an actor framework while Axum is a web framework. The README here lists no benchmarks, so any throughput comparison would have to come from elsewhere.

## Sources

- [actix/actix on GitHub](https://github.com/actix/actix)
- [Issues](https://github.com/actix/actix/issues)
- [License: Apache-2.0](https://github.com/actix/actix/blob/main/LICENSE)
- [README](https://github.com/actix/actix/blob/main/README.md)
- [Releases](https://github.com/actix/actix/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/actix-actix