/*:#localized(key: "DistributedLocationTransparency")
 # Location transparency: the payoff and the price

 The headline feature is **location transparency**: you call a distributed
 actor the *same way* whether it happens to live in your own process or on a
 server across the country. The actor system resolves where it is and routes
 the call. Your code that says `try await ledger.currentBalance()` doesn't
 change based on the answer.

 That's genuinely powerful. You get to reason about your system as a set of
 actors sending each other messages, and let the runtime handle the plumbing of
 *where* each actor sits, which can even change as you scale or move services
 around.

 But transparency is about *how you write the call*, not about what the call
 *costs*. Be clear-eyed about the price, because it's real:

 * **Latency.**  
 A local actor hop is nanoseconds. A network round trip is
 milliseconds, often thousands of times slower. Chatty back-and-forth that's
 fine in-process can crawl across the wire. You'll want to send fewer, larger
 messages rather than many tiny ones.
 * **Partial failure.**  
 In one process, if your code is running, the actor
 exists. Across a network, the other side can vanish mid-conversation: crashed,
 rebooted, unreachable. That's the `throws` you keep seeing. You have to
 *design* for calls that don't come back, not treat failure as a rare
 surprise.
 * **Serialization.**  
 Every argument and result is encoded and decoded. That
 costs CPU and, more subtly, constrains your API: you can only exchange things
 that fit through `Codable`. Rich in-memory graphs and live resources stay
 home.

 Location transparency doesn't make these costs disappear; it makes them
 *uniform to call*. Knowing they're there is what keeps you from designing a
 distributed system as if it were a local one.

 [Previous](@previous)  |  page 7 of 9  |  [Next: When It Matters](@next)
 */
