"構文が美しくあっても、動かすものが歪めば、それは設計の破綻となる。"

Rustの async / await 構文は、洗練された非同期設計を可能にした。
だがそれは単体で完結する仕組みではない。
実際に非同期処理を駆動するには、「ランタイム」というもうひとつのエンジンが必要となる。

その代表例が、tokio と async-std。
これらは単なる技術選択に見えるが、Rustの非同期構文の“実行哲学”を決定する分岐点でもある。

本稿では、非同期ランタイムが担う構造的意味と、tokio / async-std が内包する思想の違いを掘り下げていく。

なぜRustに“ランタイム”が必要なのか？

Rustの async fn は「未来を返す関数」に過ぎない。

async fn greet() -> String {
    "hello".to_string()
}

この関数を呼び出しても、それだけでは実行されない。
返ってくるのは impl Future<Output = String> という未評価の状態オブジェクトである。

これを「進める（poll）」にはランタイムが必要だ。

ランタイムとは、非同期の“時間”を駆動する実体である。

tokio：性能と統制の王国

tokio はRust非同期界で事実上のデファクトスタンダード。
その特徴は、明確な責任設計とパフォーマンス主義にある。

#[tokio::main]
async fn main() {
    println!("hello from tokio");
}

この構文が表しているのは、「非同期の駆動系は tokio が統治する」という、構造的な集中設計である。

tokioはランタイムそのものが“設計の中枢”として振る舞う。

async-std は、「非同期も同期のように書ける」を目指した構文至上主義のランタイムだ。

use async_std::task;

fn main() {
    task::block_on(async {
        println!("hello from async-std");
    });
}

これは、非同期であることを“意識させない”構文美学であり、
「実装者ではなく、設計者にやさしい」思想が流れている。

これは単なる技術選好ではない。
**どのように非同期を「言語と社会に接続するか」という“構造設計の分水嶺”**なのだ。

Rustはこのどちらも許している。
だが許しているだけでなく、「その選択がコード全体の設計論にどう波及するか」を型と構文で可視化できる。

これは極めて異質だ。
多くの言語ではランタイム選択が“設定ファイル”の中に隠れてしまうが、
Rustはそれを**“構文の文体”として表現させる**。

RustではランタイムがAPIに深く食い込む。
たとえば tokio::spawn や tokio::select! のように、
構文そのものが**「これは tokio の世界で書かれている」**という構造的印を持つ。

これは、「言語がランタイムを内包しない代わりに、設計者に選択と責任を与える」設計である。

Rustにおいて tokio や async-std を選ぶことは、
ただのライブラリ選定ではない。

それは、「設計とは構文を決めることである」というRustの美学への応答であり、
ランタイム選択は、最初の“文体選択”に等しい。

"Rustの非同期において、ランタイムを選ぶとは、設計の未来に哲学を埋め込むことである。"