- Published on
Scarfはなぜ7年使ったHaskellを惜しみつつ手放したのか — 言語選択の本当のコスト
- Authors
- Name
- Youngju Kim
- @fjvbn20031
はじめに — 好きな言語を手放すということ
「言語を乗り換えた」という記事は、たいていその言語への不満をぶちまける場になりがちです。ところが2026年7月にScarfの創業者Avi Pressが公開した文章は、正反対のトーンでした。タイトルからして、Haskellを「惜しみつつ(reluctantly)」手放した、とあります。彼は16年来のHaskellファンで、Scarfは7年間プロダクションでHaskellを動かしてきました。本人いわく、こうした文章はめったに書かないそうです — 何かを作って広めるほうが好きで、批判は得意ではない、と。
この文章が投げかける問いは、良い問いです。まだ好きな言語を、チームはいったい何ゆえに捨てることになるのか。裏切られた言語でも、押しつけられた言語でもなく、自ら選び、公の場で擁護もできる言語をです。この種の問いへの答えは、ありがちな言語論争の燃料よりもおおむね正直です。書き手に振り下ろすべき斧がないからです。
だからこそ読む価値があります。ScarfはHaskellが壊れたから離れたわけではないからです。むしろHaskellは約束の多くを守りました。そして人々が「なぜHaskellをやめるのか」と問うときに真っ先に挙げがちな理由 — 採用が難しい、人が見つからない — は、この文章のどこにも出てきません。Aviが挙げる理由は、もっと具体的で、もっと2026年的で、噛みしめる価値があります。
壊れなかった約束 — Haskellが守ったもの
まずは貸方から始めましょう。Aviは、ScarfがHaskellを本気のプロダクション試験にかけ、その約束の多くが実際に守られたと明言します。コードは信頼でき、型システムは本物のバグを捕まえ、言語はドメインを丁寧にモデリングすることを強いました。契約上のSLAを負うサービスを何年も問題なく運用し、高性能なコードも概ね素直に書けたといいます。
スタックも具体的です。APIはServantとBeamをPostgreSQLの上に重ねて構築し、トラフィックの多いScarf GatewayはWAIの上に直接、性能重視のサービスとして実装しました。これらは実際に大量のオープンソースパッケージのトラフィックを支えました。
もっとも正直な一節はこれです。Pythonへ移って手放した型安全性が、今のところ具体的に困った場面はない、と認めるのです。熱心な型システムのファンがこう言うのは重みが違います。もちろんこれは諸刃です — 型が静かに防いでいた事故は、そもそも目に見えないものですから。それでも彼は失ったものを誇張しません。
ここには個人的な色合いもあります。AviはHaskellを学んだことで格段に良いプログラマーになれたと述べており、その負い目が文章から伝わってきます。惜しさの源はそこにあります — これは恨みを晴らす文章ではなく、長い関係を結び直す文章なのです。この記事を言語を叩く弾薬として引用する前に、その点は心に留めておく価値があります。
本当の理由 — コンパイル時間とエージェントの経済学
では何が問題だったのか。Aviが挙げる最大の二つは、コンパイル時間とエコシステムの摩擦です。とりわけコンパイル時間が核心で、ここから話がはっきりと2026年的になります。
温まったループなら1サイクルは20秒ほどで、そのときは気分がいいそうです。問題はコールドスタートです。複数のAIコーディングエージェントに、それぞれ別のブランチを並行して任せる開発スタイルを想像してください — 五つのエージェントが五つのブランチを同時に探索する、といった具合です。各ブランチには、使い捨てできるクリーンなビルド環境が要ります。エージェントが数分でもっともらしい変更を書き上げ、そのあとコールドビルドの完了を15分も待つなら、コンパイラはもはや ささいな不便 ではなく、その作業の流れにおける 最大のコスト になります。
キャッシュで対応できるのでは、と思うかもしれません。Aviの答えは冷静です。キャッシュは決して完璧にはならず、それを十分に良くするためのエンジニアリング努力そのものが問題の一部だ、というのです。実際チームは、ビルド・キャッシュ・Nix・開発環境・CIの調整に多くの時間を費やしました。
核心は経済学の組み替えにあります。エージェントはコードを生成するのは安く、詰まったときに高くつきます。Haskellはコンパイル時にエラーを捕まえることに最適化された言語です — 人間がボトルネックだった時代には、それは確かな美点でした。しかしLLMが動くコードを一瞬で吐き出す時代には、その美点の相対的な価値は下がります。 言語が悪くなったのではなく、何が高くつくのかが変わった のです。
言い換えるとこうです。何十年ものあいだ、通説はエラー検出をできるだけ前倒しにせよ、でした — シフトレフト、深夜3時ではなくコンパイル時に落ちよ、と。その論理は、コードを書く人間こそ希少資源だという前提に立ちます。希少資源を、数秒で候補を吐き出す疲れ知らずの生成器に置き換えると、ボトルネックはフィードバックループの遅延へと移ります。速いが賢くないループが、遅いが賢いループに勝てるようになったのです。居心地の悪い考えですが、Aviはそれを取り繕いません。
Aviはコミュニティの方向性への物足りなさも短く覗かせます。ビルド時間・オンボーディング・ドキュメント・例・ツールよりも型システムの研究が優先されがちだという感覚、そしてAIについては、活用(enablement)よりも制約(restriction)に会話が寄りがちだ、という点です。
エコシステムの摩擦がここで何を意味するのかは、はっきりさせておく価値があります。Aviはライブラリが未成熟だとか、何かが動かないと不平を言っているのではありません — 上記のスタックは何年も出荷され続けました。摩擦はコードを取り巻く機械仕掛けのほうにあります。速いエージェント的ワークフローが絶えず頼るビルド・キャッシュ・環境・CI、そして関心が別のほうを向いたコミュニティです。ありがちな不平とは違う、だからこそ興味深い不平なのです。
どう去ったか、そして残る教訓
移行そのものは教科書的です。新しいAPI作業はすべてPythonで始め、PythonサーバーをHaskellサーバーの隣に並べて立て、リクエストを適切なほうへ振り分け、触れた機能から一つずつ移していきます。ストラングラーフィグ(strangler fig)パターンそのものです。既存コードの移植は、機械的な作業をLLMに任せることでかなり楽だったといいます。そして今もHaskellはプロダクションで動いており、チームは依然としてHaskellに敬意を払っています。
静かな皮肉を一つ挙げておく価値があります。留まるコストを押し上げたまさにその能力 — LLMがコンパイラをボトルネックにするほど速くコードを生成する能力 — が、去るコストを安くしたのです。歴史的に過酷な作業だった別言語への移植が、モデルが一行ずつ運んでくれることで、いまや大部分は機械的な仕事になりました。作る経済学を変えた道具が、移す経済学まで変えたわけです。
成果も正直に書かれています。テストカバレッジはかつてないほど良くなり、ホットフィックスは今やSlackのメッセージ一つで出せるそうです。しかしAviは勝利を誇張しません — PRのスループットが明らかに増えたとは言いがたく、コミット数はノイズが多く、コード行数は良い指標ではない、と自ら釘を刺します。
ここから得る教訓は「Haskellはダメだ」ではありません。言語の適合性は絶対値ではなく、私たちがどう作るかに対する相対値だ、ということです。7年前のHaskell選択が間違いになったのではなく、盤面がその下で変わったのです。そしてこの決定全体は一つの前提の上に立っています — エージェント中心の開発が、これからこのチームがソフトウェアを作る方法だ、という前提です。それが正しければ、この移行はAviの言うとおり、明快で論理的な次の一手です。前提が揺らげば、計算も変わります。
そしてリスクにも名前をつけておきましょう。検証された強みを賭けと引き換えにするのは、やはり賭けです。エージェント中心の開発が頭打ちになったり、型が捕まえていた目に見えないバグが規模とともに表面化し始めたりすれば、1年後の帳簿は違って見えるかもしれません。測れない利得についてのAviの正直さは諸刃です — コストもまた、やって来るまでは同じように見えにくいのですから。
つまりこれはn=1の話であり、一社の経済学です。「みなPythonで書き直せ」という処方ではなく、あなた自身のボトルネックがどこへ移ったかを正直に測り直せ、という誘いに近いのです。
おわりに
ここで最も学ぶべきは、結論ではなく姿勢です。AviはHaskellが得意だったことをはっきり認め、得たものを誇張せず、自分の決定が特定の前提の上に立つことも隠しません。言語を去る文章がこれほど均衡を保つのは簡単ではありません。スタックが何であれ、その正直さ — 守られたもの、変わったもの、まだ不確かなものを切り分ける規律 — こそ、真似る価値のある部分です。
より広い信号を読むなら、こうかもしれません。AIがコードの書かれ方を変えるにつれ、私たちが言語を格付けする軸が静かに回転しています — 言語がどれだけ多くを防ぐか、から、どれだけ速く再挑戦させてくれるか、へと。それが進歩なのか罠なのかは、まだはっきりしません。ただ、この回転に早く気づき、自分たちの数字に正直でいるチームのほうが、古いボトルネックを最適化し続けるチームよりも良い判断を下すでしょう。