/* Page prose (ja) */
"DistributedLocationTransparency" = "# 位置透過性: 見返りと代償\n\n目玉となる機能は**位置透過性**です。分散 actor を、それが自分のプロセスに存在しようと、国の反対側のサーバーに存在しようと、*同じやり方*で呼び出します。actor システムがそれがどこにあるかを解決し、呼び出しを経路づけます。`try await ledger.currentBalance()` と書かれたコードは、その答えによって変わることはありません。\n\nこれは本当に強力です。自分のシステムを、互いにメッセージを送り合う actor の集まりとして考えられるようになり、各 actor が*どこ*に位置するかという配管をランタイムに任せられます。その位置は、スケールしたりサービスを動かしたりするにつれて変わることさえあります。\n\nしかし透過性とは、*呼び出しをどう書くか*についてのものであって、呼び出しが何を*コストとするか*についてのものではありません。代償についてははっきりと目を開いておきましょう。それは現実のものだからです。\n\n* **レイテンシ。**  \nローカル actor のホップはナノ秒です。ネットワークの往復はミリ秒で、しばしば数千倍も遅くなります。プロセス内では問題ない、おしゃべりなやり取りも、回線越しでは這うように遅くなりえます。多くの小さなメッセージよりも、数の少ない、より大きなメッセージを送るのがよいでしょう。\n* **部分的な失敗。**  \n1 つのプロセスの中では、コードが実行されているなら、actor は存在します。ネットワークをまたぐと、相手側は会話の途中で消え去ることがあります。クラッシュした、再起動した、到達できない。それがずっと目にしてきた `throws` です。失敗をめったにない驚きとして扱うのではなく、戻ってこない呼び出しに向けて*設計*しなければなりません。\n* **シリアライズ。**  \nあらゆる引数と結果がエンコードされ、デコードされます。それは CPU のコストがかかり、そしてより微妙な形で API を制約します。`Codable` を通り抜けられるものしかやり取りできないのです。メモリ内の豊かなグラフや生きたリソースは家にとどまります。\n\n位置透過性はこれらのコストを消し去りはしません。それらを*呼び出しの面で均一*にするだけです。それらがそこにあると知っていることこそが、分散システムをまるでローカルのシステムであるかのように設計してしまうのを防いでくれます。\n\n[前へ](@previous)  |  7 / 9 ページ  |  [次へ: いつ重要になるか](@next)";
