7年間の運用を経て、ScarfがHaskellから脱却した意外な理由

Scarfが7年間にわたる本番環境での運用を経て、苦渋の決断を下しました。同社はHaskellから他の技術スタックへの移行を進めています。長年親しんだ関数型言語の牙城を去るという決断に至った経緯や、移行の背景にある技術的な葛藤について、彼らの公式発表からその詳細を探ります。

うわ。Haskellユーザーじゃないけど、表現力の高い型システムを持つ言語（主にScala、一部Rust）をよく使ってる。自分の経験は全く逆だな。LLMが吐き出すゴミみたいなコードを捕まえるのに、優れた型システムがない言語を使うなんて想像できないよ。実際、LLMのおかげで表現力の高い言語を使うコストが下がったんだから、Pythonみたいに型システムの貧弱な言語からはみんな離れていくと思ってたんだが。

身も蓋もない言い方をするつもりはないけど、この記事を要約すると「今はアプリ開発を『バイブコーディング（ノリで書く開発）』でやってるから、偉大なる（ほぼ全知全能の）Haskellコンパイラは、エージェントが正解にたどり着くまで何度も試行錯誤させるには遅すぎる」って言ってるだけだよね。

自分はHaskell開発者じゃないし、「Scarf」という会社も聞いたことがなかった。

代わりのエコシステムを築こうと尽力した彼を尊敬しつつも、Haskellのコンパイル時間が理由というより、単にPythonの方がエンジニアを見つけやすいし、LLMにとって事実上のスクリプト言語だから移行したんじゃないかという印象を拭えない。

もちろん、それが悪いことだとは思わないよ。会社を経営するのは大変だし、技術への美的観点からの情熱や理想だけでやっていけるのは若いうちだけ。ある年齢を過ぎれば、お金を稼いでプロとしての目標を達成することの方が重要になるからね。

この記事の前提には強く同意するよ。だからこそ著者がHaskellからPythonに乗り換えたことに驚いている。

しばらく前から、特に並行作業を行う場合、エージェントが効率的に動くには高速なコンパイル時間が不可欠だと痛感していた。それと同じくらい明白なのは、エージェントの出力を制限するために強力な型システムと狭いガードレールが必要だということ。この2点は自分にとって明確だったから、著者と同じく、その両方を最大化できる言語エコシステムを選びたかった。表現力の高い型システムと高速なコンパイル時間を両立する言語は『存在する』んだ。著者はコンパイル時間がゼロであることが許容されると判断する前に、それらを検討したんだろうか？

自分の場合はOCamlに行き着いた。他にも選択肢はあると思う。型定義が少なくてコンパイルが速いGoや、型は多いけどコンパイルが遅いRustとかね。自分の直感ベースの評価ではOCamlがベストで、今のところかなり満足しているよ。

参考までに、自分は金融取引所のBitnomialでHaskellを本番環境で使っているけど、LLMとHaskellの組み合わせはめちゃくちゃ生産性が高いよ。

Opus 4.6以降、LLMはServantやBeamみたいなライブラリで高度な型を扱うのがかなり上手になった。型の表現力の高さとコンパイラからのフィードバックがあるおかげで、エージェントはすぐに動くものへ収束してくれる。コンパイル速度が問題になるほど、エージェントに何度もコンパイルさせなきゃいけないなんて感じたことはないな。

記事の内容はいいと思うけど、コンパイル時間が占める割合を大きな問題として捉える点には少し異論がある。

もしコードを書くのに2日かかって型チェックに20分（確かに長いけど）かかっていたのが、LLMでのコード生成に10分、型チェックに20分になったとしても、その割合の変化だけで言語を変える理由にはならないはずだ。

結局2日近く短縮できているわけで、20分を20秒にしたところで機能のリリースが劇的に速くなるわけじゃない。でも強力な型は依然として重要だし、現時点でLLMが『これで合ってるはずだ』と思い込んでいるものに取って代われるとは思えないな。

とはいえ、Haskellがもっとコンパイルを高速化すべきだという意見には同感。強力な型があるんだから、少なくとも型チェック速度で素晴らしい成果が出せるはずだよね。

良い投稿だね。AIの登場でプログラミング言語のトレードオフは変わった。HaskellとPythonの両方を使っている会社を経営している身として、Haskellがこの新時代に適応できることを願っている。

長年両方の言語を本番運用してきた経験から、一つだけ付け加えたい観察がある。

Haskellは『プラットフォーム』の開発に優れていて、Pythonは『プロダクト』の開発に優れているということ。

うちはインフラチームがHaskell（最近はRustも）を使い、プロダクトチームはPythonを使っている。これによって、プラットフォーム側では高速かつ堅牢なインフラを、プロダクト側では開発スピードと迅速なイテレーションを両立できるという、両方のいいとこ取りができているんだ。

この構成で何年も上手くいっているけど、新しいAI時代になってこれがどう変わるのか、あるいは変わらないのかはまだ分からないね。

正直、この考え方には驚いた。

うちは10年以上Haskellを使っている開発現場だけど、Haskellを使ったエージェント開発はかなり上手くいっているよ。

Haskellのクリーンビルドが遅いのは確かに辛いけど、実際の日々の開発でそんなに頻繁に実行するわけじゃないし、それはエージェントを使っても同じことだ。

Scarfの現場でそれほど頻繁にコンパイル時間の痛みに直面するようなプラクティスが、果たしてHaskellを捨てるほどの価値があるのかどうかは疑問だ。もしかしたら彼らにとっては正解なのかもしれないけど、自分にはそうは思えない。

OCamlは彼らの問題に対する明白な解決策なのに、言及すらされていないことに衝撃を受けている。型安全性を犠牲にすることなく、高速なコンパイル時間を得られるのに。

こういう記事が出るたびに、なぜかAIの話題にすり替わっちゃうね。これに関する研究って何かあるのかな？ LLMにとって型付き言語がどれくらい有利なのか。言語そのものよりも、データの量やスケーリング則の方がLLMのコーディング能力には影響していると思うんだけど。