7月10日、Avi Pressが「After 7 years in production, Scarf has reluctantly moved away from Haskell」と題した記事を公開した。オープンソースパッケージの配布分析を手がけるスタートアップScarfが、7年間維持してきたHaskell製バックエンドをPythonへ移行するに至った経緯と、その背景にある「AI時代の開発ループとコンパイル時間の相性問題」について詳述した内容だ。

著者のAvi Press氏はScarfのCEOであるとともに、Haskell FoundationのボードメンバーおよびHaskell.orgの委員会メンバーでもある。Haskellコミュニティのリーダーシップにある人物が「渋々（reluctantly）移行した」と書いたという文脈が、この記事に単なる「Haskellはダメ」論とは異なる重みを与えている。

7年間、Haskellは実際に機能していた

ScarfのバックエンドはServantとBeam（PostgreSQL向けORM）を使ったメインAPIと、WAI（Web Application Interface）上に直接構築した高性能ゲートウェイサービスの2本柱だった。後者はオープンソースパッケージのダウンロードパスに直接置かれた、契約上のSLAを持つ本格的な本番システムだ。

Avi Press氏はHaskellの成果を率直に評価している。型システムは実際のバグを捕捉し、高性能なコードの実現も概ね直感的だった。問題はコードの品質ではなく、コンパイル時間とエコシステムの摩擦だった。Nix（再現性の高いビルド・開発環境を実現するパッケージマネージャ）、キャッシュ、CI、開発環境の整備に多大な時間を費やし続けた。それでもチームがHaskellとツールチェーンを深く習熟していた間は許容範囲内だった。

転機はAIだった。

「コンパイル待ち」がAI時代の最大コストになった

これがこの記事の核心だ。

従来の開発では、エラーを捕捉する場所は「コンパイル時」か「実行時」の2つだった。LLMの登場により、「コード生成時」という第3の場所が加わった。モデルがコンパイラに渡す前に間違いを回避できるなら、コンパイル時型検査の相対的な価値は変わる。

問題はコンパイル時間だ。エージェントが数分でコードの変更案を生成できるとして、プロジェクトのコールドビルドに15分かかるなら、コンパイラは「紙の切り傷」から「最大のコスト」に変わる。

さらに深刻なのが並列エージェント開発との相性だ。複数のgit worktreeを立ち上げ、複数のエージェントに並行して異なるアプローチを試させ、結果をレビューして良いものを残す——これが今の開発スタイルだ。このとき、コールドスタートのコストは並列数だけ乗算される。5つのブランチに5つのエージェントを走らせたいとき、Haskellのビルドコストは実質5倍になる。

キャッシュが完璧に機能すれば20秒のフィードバックループも可能だが、それはベストケースに過ぎない。変更がビルドグラフの深い部分に及ぶほどキャッシュは効かなくなる。エージェント中心のワークフローでは、コールドスタートケースと平均ケースこそが最適化の対象となる。

「（キャッシュが）うまく機能すれば、とても速い。でも、それはベストケースで、システム全体をベストケースに最適化することはできない。」

移行先にPythonを選んだ理由

Avi Press氏がPythonを選んだ主な理由は、LLMとの親和性と採用のしやすさだ。LLMはPythonのコードを最も多く学習しており、エージェントが生成するコードの品質と量で圧倒的な優位がある。また、Haskellの深い知識を持つエンジニアの採用が難しいという問題も以前からあり、Pythonへの移行はその解消にも寄与する。

移行戦略は大規模な切り替えではなく段階的な並走だ。PythonのAPIサーバーをHaskellのサーバーと並べてデプロイし、新しいAPIルートはPythonに、既存のHaskellコードはそのまま動かし続ける。時間をかけてPythonが主系となり、Haskellのフットプリントは縮小していく。

認証、DBアクセス、共有モデル、デプロイイメージ、テストのポートは以前なら高コストだったが、「LLMにとって既存コードの別言語への移植は得意分野だった」とAvi Press氏は述べている。移行後の効果として挙げているのは以下のとおりだ。

• ツールチェーンに費やしていた時間が機能開発とテストに回った
• テストカバレッジはかつてないほど高くなった
• 「カスタマーコールからバグ修正のデプロイまで、通話を終える前に完了することがある」

型安全性の喪失については「今のところ具体的な問題として表れていない」と率直に述べている。

HaskellコミュニティへのAvi Press氏の問いかけ

Avi Press氏はScarfの事情を超えて、Haskellエコシステム全体への懸念を表明している。

Haskellコミュニティの一部には「LLMを使うな」「LLMを含むワークフローをサポートしたくない」という声がある。これを氏は「歴史の誤った側にいる」と明言する。AI対応のHaskellエコシステムが答えるべき問いは、型システム研究ではなく以下のようなものだという。

• エージェントがHaskellをうまく使えるようにするにはどうするか
• プロジェクトのブートストラップを速くするにはどうするか
• エラーメッセージをエージェントが修正しやすい形にするにはどうするか
• コールドビルド時間を下げるにはどうするか
• ライブラリドキュメントをコピペ可能な実例で埋めるにはどうするか

「依存型（dependent types）のような新機能は面白い。しかし産業用Haskellのユーザーはコンパイル時間とエコシステムの摩擦を何年も訴えてきた。AI時代において、それらは単なる不満を超え、言語エコシステムとの根本的なミスアラインメントになった」というのがAvi Press氏の結論だ。

Haskellの強みを誰より理解している人物が、それでも移行を選んだ。その判断の根拠と、Haskellコミュニティへの具体的な提言は、言語選択や開発ワークフローを再考している開発者にとって読む価値がある。

詳細はAfter 7 years in production, Scarf has reluctantly moved away from Haskellを参照していただきたい。