
2026/07/10 22:30
7年もの間開発が続けてきたScarfが、Haskellからしぶしぶ離れることに至った
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Haskell財団の理事会メンバーであるAvi Pressは、Scarfが新開発のため Haskell から Python へ移行した最近の変化について、AI の時代における経済的なトレードオフの変化への戦略的対応であると説明しています。16 年にわたる成功した運用利用(Servant、Beam、WAI といったライブラリに依存し、高い稼働率と SLA 準拠を達成)があった後でのこの移行は、技術的な失敗が要因ではなく、大規模言語モデル(LLM)によって開発の経済性がどのように変化したかによるものです。LLM は「コード生成時間」を新たなコストの次元として導入しました。エージェントが数分でコードドラフトを作成できるようになった際、長時間の Haskell コンパイルサイクル(特にコールドスタート)はマルチエージェントワークフローにおいて軽微な制約以前に主要なボトルネックとなりました。Scarf は新 API ワークについては Python へ移行しつつ、一部の Haskell サービスを維持し、リクエストを適切にルーティングしながら、劇的なカットオーバーなしで Haskell の足元を徐々に縮小しています。現在では LLM を用いることで、認証やデータベースアクセス、共有モデルといったコアな責任領域の移植が容易になり、エンジニアは既存コードの維持に留まらず再実装を行えるようになりました。複雑なツールの回避によって得られた時間を、より多くの機能のリリース、包括的な AI 支援テスティングの実行、および顧客からのフィードバックから数時間以内(数日や数週間ではなく)へのホットフィックス適用に再投資しています。PR のthroughput メトリクスはノイズが混ざっていますが、全体的な生産性向上は明確で、Avi は競合他社がより速い開発サイクルを有利利用して、ますますエージェント主導の環境におけるイテレーションを加速させるリスクがあるため、レガシースタックに固執することは停滞をもたらす危険があると述べています。彼によれば、Haskellエコシステムは AI エージェントにとって最適化されることで関連性を維持する必要があると主張し、純粋な型系研究以前にビルド時間、オンボーディング、ドキュメント例、ブートストラップ速度、エラーメッセージを優先すべきだと指摘しています。また、LLM に反対する有害な一群が言語の将来に悪影響を及ぼす可能性もあるとも述べています。
本文
Scarf の Haskell から Python への移行と、AI 時代におけるエコシステムの課題
Avi Press | 2026 年 7 月 10 日
免責事項
- この記事の執筆は著者にとって非常に困難なものでしたが、構築とプロモーションを好む立場にあるため、実際にほとんど執筆しませんでした。
- Haskell を批判する意図はありません。 本書は著者が Haskell にどれほど心血を注いできたかを示す意味を含みます。
- Scarf が Haskell から退避せざるを得なかった経緯について率直に共有し、コミュニティへのフィードバックとして真摯な検討を促します。
私が行ってきたこと(実績と課題)
長年の貢献
- 過去16 年間、Haskell を熱烈に支持し、人生において最も重要なプログラミング言語としました。
- Haskell Foundation の理事会およびHaskell.org 委員会の一員として貢献。
- Haskell で稼働する企業を設立し、同言語の利点を広く広めました。
本番環境での実績(Scarf)
- バックエンド: Haskell で構築済み。
- 主要 API:
上にPostgreSQL
やServant
を使用して実装。Beam - Scarf Gateway: Open Source パッケージの高速ダウンロード用に、高パフォーマンスな Haskell サービスを構築(
ベース)。WAI - これらのシステムは長年、実際の稼働時間要件と**SLA(サービスレベル合意)**を確実に遵守してきました。
- 型システムによるバグ検出、コードの高信頼性、ドメインモデルへの深い思考促進など、期待通りの成果がありました。
直面した本質的な課題:AI と開発サイクルの変化
- 最大のボトルネック: コンパイル時間とエコシステム内の摩擦(friction)。
- ビルド最適化の限界: Nix 環境やキャッシュ管理などに多くの時間を費やしてきたが、これには限界がありました。
- LLM の台進によるパラダイムシフト:
- AI はコード生成において極めて高い能力を発揮し、開発経済性を変えています。
- エラー検出の主要場所が「実行時」に加え、「コード生成時(コンパイル以前)」にシフトしました。
- 重要指標の変化:
- 人間開発:長時間のコーディング中に長くても我慢できるコンパイル待ち。
- AI アジェント開発:数分でドラフトを作成しても、ビルドで**15 分待たされる場合、コンパイラは「支配的なコスト」**へと変化します。
「冷たい起動(Cold Start)」の重荷
- 並列処理における問題:
- 複数の AI エージェントを並列で使用する場合、各ワークツリーに対して長すぎる Haskell コンパイル時間は致命的です。
- 新しいブランチごとに長いビルド時間や複雑なキャッシュ設定が必要なら、**「コスト税(tax)」**がかかり始めます。
- 5 つの代理プログラムが同時に探索する場合、このコストは指数関数的に増大します。
- 完全なキャッシュ化の非現実性:
- キャッシュ化は完璧ではなく、それを維持するためのエンジニアリング努力自体がコストになります。
- エージェント主体のワークフローでは、安価で使い捨て可能な実行コンテキストを必要としており、Haskell の現在の環境ではそれが不足していました。
私たちの移行方法:戦略的アプローチ
- 段階的な移行戦略:
- すべての新規 API 開発をPythonに切り替え。
- Python サーバーと Haskell サーバーを並列展開し、リクエストを適切にルーティング。
- 新機能を順次 Python に移管し、既存の Haskell コードは保留して足跡を縮小。
- リスク管理:
- 劇的な切り替えリスクを抑えつつ移行を実現。
- LLM を活用することで、認証・DB アクセス・共有モデル・デプロイメントイメージなどの中継(glue code)の再実装コストを大幅に削減。
- 既存コードの移植は現在、AI の力で比較的容易です。
生産性向上の実証
- 時間配分の最適化:
- 待機やツールチェーン格闘で失っていた時間を、機能実装と包括的なテスト作成(AI による)に再配分。
- プロセスの高速化:
- チケット登録 → PR 作成 → レビュー/反復 → マージ → デプロイまでの期間が劇的に短縮。
- 会話終了前にバグ修正を配信できるレベルへ達しました。
- 品質と透明性:
- 手放した型安全性の代わりに、テストカバレッジは過去最高を更新。
- バグ発生時でもスラックメッセージ一つでホットフィックスが完了するほど迅速化。
- 生産性の向上と新たな技術分野での活躍により、エンジニアリングチームは鼓舞されています。
Haskell エコシステムの問題と将来展望
現在の危機的状況
- AI は退去しません:
- AI を活用しない人々やエコシステムが競合する世界では、熟練した AI サポートエンジニアの方が遥かに速く動きます。
- 数週間かかっていた作業を数日で完了させるのは現在常識です。
- 停滞と機会費用:
- Haskell のツールチェーン進捗は、業界全体の AI エイジによる加速から取り残されているように見えます。
- この**機会の損失(opportunity cost)**はこれまで以上に重要になっています。
コミュニティへの要請:視点の転換
- 「制限」ではなく「適応」:
- 単に「LLM を使わない」という立場だけでなく、エコシステム全体が AI とどう共existするかを考える必要があります。
- 開示(AI 関与度、モデル使用、レビュープロセス)は規範として必要です。
- 解決すべき核心課題:
Haskell の世界を AI 時代に合わせて最適化するには、以下の問いに答える必要があります:
- エージェントにとって使いやすくする方法是?
- モデル学習データへの高品質な Haskell 例の取り込みは?
- レビュープロセスのスケーリングは?
- ドキュメントにコピー&ペースト可能な現実的例を含めることは?
- プロジェクトの起動(bootstrap)と冷たいビルド時間の削減は?
- エラーメッセージのエージェントフレンドリー化は?
結論:AI を第一級の存在として取り込むこと
- 型安全性だけでは不十分:
- 型安全性はコンパイラによる迅速な収束を助けますが、エージェントには異なるボトルネック(生成コスト vs ブロックコスト)があります。
- エージェントが必要とするのは:高速フィードバック、明確な例、低い設定摩擦、迅速な修復サポートです。
- 優先課題の再定義:
- ビルド時間、オンボーディング、ドキュメント、例、ツール、エージェントワークフローなどへの注力は、型システム研究よりも重要視されるべきです。
- 依存型などの新機能も大切ですが、産業界が長年抱えてきたコンパイル時間と摩擦の問題を解決しないと、根本的な不一致が解消されません。
著者の決意
- Scarf は Haskell を尊敬し続けていますが、新規プロダクト開発では AI ツールを活用したペースアップのために Python に移行しました。
- これは状況に対する明確で論理的な前進であり、コミュニティも同様の緊急感を持って対応することを願っています。