makoto-developer's テックブログ

2026年8月の記事 6件

すべての記事へ

連載最終回。注文処理ワークフローを素直な手続き型と射の合成の両方で実装し、行数・アロケーション・レイテンシを測った。同じ機能なら1ステップあたり+30nsの追加コスト、9ステップ目から行数で得。同じ定義から実行・dry-run・Mermaid図・設定一覧の4つが導ける。そして正直に書く——型で進捗を保証することを諦めた場所、スタックトレースが深くなってステップ名が出なくなった場所、これはやりすぎだと判断した場所。

Functor から Applicative、Monad へ積み上げると、バリデーションのエラーが1件から3件に増える。式木を fold ひとつで畳んで評価・整形・簡約を書き分け、代数の積で木を1回だけたどる。iter.Seq が CPS 的な形をしていること、そして iter.Pull がスライス直走査の120倍遅いこと。最後に Go の天井——高階カインド多相の不在——を正面から測り、回避策3種のコストを比べる。

Goの標準ライブラリと日常のコードから Functor・Monoid・Kleisli合成・自然変換を取り出し、法則をテストで検証する。今回わかるのは「法則は最適化の許可証だ」ということ。ループ融合でメモリが半分以下、同じモノイドの実装差で55倍、並列畳み込みの損益分岐点は2〜3万要素。平均が並列化で壊れる様子と、その直し方も実演する。

圏論の解説はHaskell前提のものばかりで、Goを書く人には縁遠く見える。でも圏論が扱っているのは特定の言語機能じゃなく「合成」そのもの。第1回は、Goの型と関数が圏をなすことをproperty-based testで確かめ、純粋性が何を守っているのかを実際に壊して示し、合成のコストをベンチマークで測る。合成した関数は変数に入れて使い回せば手書きとの差が1ns未満と安く、呼ぶたびに組み直すと7倍以上遅い。