Go

言語別の既定§2-2

選ぶ場面§2-10

• Kubernetes・クラウドのコントロールプレーンを扱う
• 中程度の常時接続＋高スループットgoroutineで並行処理が簡潔に書け、運用も単純
• サービス間のRPCProtocol Buffers周りのツールが充実し、単一バイナリで配りやすい

既定：CLIツール作成物ごとの言語の決め方

乗り換える条件

• Rust起動時間・バイナリサイズ・処理速度を詰めたい
• TypeScript（Bun）社内向けでnpmの資産を使いたい

既定：インフラ系ツール（Kubernetes Operator、Terraformプロバイダ等）作成物ごとの言語の決め方

代替：一般的なWeb API・SaaSのバックエンド作成物ごとの言語の決め方

既定は TypeScript（フロントと1言語に揃う）。3人以上で公開APIを長期運用するとき（§2-10 手順3） に乗り換える。

代替：開発者向けツール（Linter、フォーマッタ、ビルドツール、パーサ）作成物ごとの言語の決め方

既定は Rust。処理が軽く、開発速度を優先したいとき に乗り換える。

代替：データベース・検索エンジン等の基盤ソフト作成物ごとの言語の決め方

既定は Rust。GCの影響が許容できる分散系の制御部分 に乗り換える。

代替：スクリプト・社内の小さな自動化作成物ごとの言語の決め方

既定は TypeScript（Node.jsで直接実行、またはBun）。単一バイナリで配りたいとき に乗り換える。

採用の根拠§22-2

単一バイナリで配布でき、実行時の依存がない。メモリ使用量が小さく、同時接続に強い。Go 1互換性の約束により、長期間コードが壊れにくい。Docker、Kubernetes、TerraformなどインフラOSSの多くがGoで書かれている

「人材が少ないのでは」→ 言語仕様が小さく、他言語経験者なら短期間で読み書きできる

ケース別の構成§19

• 自社SaaS（B2B）バックエンド：Go（net/http＋sqlc＋pgx）。少人数ならHono
• toCサービス（Web＋モバイル）バックエンド：Hono（またはGo）
• リアルタイム系（チャット・通知・共同編集）同時接続が多い（Elixirを採用しない場合）：Go（WebSocket）＋Valkey Pub/Sub
• インフラツール・CLI言語：Go（Cobra、slog）
• 個人開発・MVPGo単体：Go＋PostgreSQL＋htmx