/*:#localized(key: "DistributedWrappingUp")
 # Wrapping up

 A **distributed actor** is the actor you already know with a network dropped
 into the middle. That one change ripples out into everything below, and none
 of it can be wished away. Read the takeaways as one running argument for why a
 local `actor` is almost always the right first answer.

 * A **distributed actor** extends the local `actor` model across processes and
 machines: the same `await`-to-call feel, but the call may cross a network.
 * It rests on four pieces: the **`distributed actor`**, its **`distributed`**
 methods, an **`ActorSystem`** (the transport that locates actors and ships
 messages), and a serializable **`ID`** that makes an actor findable from
 afar.
 * Distributed calls are `async` **and** `throws`. The `try` is there because
 the network can genuinely fail: timeouts, dropped connections, a downed node.
 Design for calls that don't come back, rather than treating failure as a rare
 surprise.
 * Arguments and return values must be **`Codable`**, because they travel as
 bytes: `Sendable` from the chapter [Global Actors and Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview) taken one step further. Design payloads as
 small, self-contained value types (like `Receipt`), not live objects or
 references.
 * **Location transparency** lets you call an actor the same way wherever it
 lives, but the costs are real: latency (send fewer, larger messages), partial
 failure, and serialization. Design with them in mind.
 * For most app developers this is a *rare* need, most relevant to server-side
 Swift and clustered systems. Don't distribute a system that fits comfortably
 in one process; understanding the model matters more than using it daily.

 [Previous](@previous)  |  page 9 of 9
 */
