Scarf、Haskellからの移行を発表

免責事項 この記事を書くのは非常に辛かった。批判するよりも構築し、促進することを好むため、書かないことも考えた。しかし、この記事がHaskellの将来に関する議論に建設的に貢献できることを願っている。 私は外部からHaskellを批判しているわけではないことを強調したい。Haskellにはそれだけ関心があり、ScarfがなぜHaskellから不本意ながら移行したのかを正直に説明することで、コミュニティの人々がこのフィードバックを真剣に受け止めるよう願っている。 私の経歴 過去16年間、私はHaskellの大ファンだった。私の人生において最も重要なプログラミング言語であったことは間違いない。Haskellを学ぶことで、私ははるかに優れたプログラマーになった。私はHaskellを擁護し、Haskellで動く会社を設立し、Haskell FoundationとHaskell.org委員会の理事を務めている。また、Haskellが改善すべきだと考える点についてもオープンに発言してきた。 Scarfがローンチして以来、私たちのバックエンドはHaskellで構築されてきた。私たちのアプリを動かす主要なAPIは、ServantやBeam on top of PostgreSQLのようなライブラリを使用している。また、WAIの直上に、大量のオープンソースパッケージトラフィックのダウンロードパスに直接位置する、高性能なHaskellサービスであるScarf Gatewayも構築した。これらのシステムには実際の稼働時間要件があり、契約上のSLA（サービスレベルアグリーメント）が定められており、長年にわたり本番環境でそれを成功裏に管理してきた。私たちはHaskellを真剣な本番テストにかけ、その多くの約束が守られた。コードは信頼性が高かった。型システムは実際のバグを捉えた。言語は、ドメインをどのようにモデリングするかについて、私たちに思慮深くさせるものだった。高性能なコードは一般的に達成しやすかった。 しかし、コストも現実のものだった。最大のものはコンパイル時間とエコシステムの摩擦だった。私たちはビルド、キャッシュ、Nix、開発者環境、CI、そして真剣なHaskellコードベースの周りに必要となるあらゆる機械装置の最適化に多くの時間を費やした。長らく、それは実行可能だった。私たちのチームは言語とツールを深く理解している。私たちはどこに落とし穴があるかを知っており、ほとんどの場合、それを受け入れていた。 AIがトレードオフを変えた LLM（大規模言語モデル）は今やコードを書くのが非常に上手くなった。もちろん完璧ではないが、ソフトウェア開発の経済性が変化するほどには十分だ。歴史的に、私はエラーをコンパイル時または実行時のいずれかで捉えるものだと考えていた。今、第三の場所がある：コード生成時だ。モデルは、コンパイラがコードを見る前に、しばしば間違いを回避できる。そして、モデルが改善されるにつれて、コンパイル時にあらゆる可能な問題を捉えることの相対的な価値は変化する。これは型安全性が無価値になったということではない。しかし、型チェックのコストは今やはるかに重要になる。LLMが数分で動作する実装を生成できるのに、コンパイルステップがそれよりはるかに時間がかかるなら、あなたの言語とビルドシステムは開発ループのボトルネックになっている。重要な指標：開発フィードバックサイクル全体にどれだけの時間がかかり、そのうちどれだけの時間がコンパイラを待つことに費やされるか？ 人間が1時間かけてコードを書くなら、長いコンパイルサイクルは迷惑だが、許容できるかもしれない。エージェントが数分で実行可能な変更の下書きを作成し、その後、コールドスタートからプロジェクトをビルドするために15分待つなら、コンパイラは単なる些細な問題から、その作業スレッドの主要なコストへと移行したことになる。これは、多くのコーディングエージェントを並行して使用し始めると、耐え難いものになる。一度に1つのことに取り組んでいるなら、コールドビルドのコストを一度支払い、その後も継続できるかもしれない。しかし、ますます、私はそのように働きたくない。複数のワークツリーを起動し、異なる作業ラインをフォークし、エージェントに試行させ、結果を確認し、有用なものを保持したい。その世界では、コールドスタート時間は非常に重要になる。新しいワークツリーごとに長いHaskellビルドが必要になったり、慎重なキャッシュ設定が必要になったり、大量のメモリを消費したりすると、新しい作業スレッドごとに税金がかかる。5つのエージェントが並行して5つのブランチを探索したい場合、その税金は倍増する。 Haskell界隈では、キャッシュ、Nix、リモートビルダーなどのツールについて多くの議論がある。それらのツールは役立つ。私たちはそれらを使用した。しかし、キャッシュは決して完璧ではなく、十分だと感じさせるために必要な労力自体が問題の一部だ。実際には、並列AI支援開発は、安価で使い捨て可能な実行コンテキストを必要とする。私は、これをフォークし、変更を試し、テストを実行し、何が起こったかを見せてほしい、と言えるようになりたい。私たちのHaskell環境は、そのスタイルの作業には十分安価ではなかった。すべてがキャッシュされており、小さな変更を加えた場合、非常に高速なコンパイルを得られることがある。時にはループは20秒で、それは素晴らしいと感じる。しかし、それは最良のケースであり、最良のケースはシステム全体を最適化できるものではない。変更がビルドプランのコア部分に深く入るほど、その話は当てはまらなくなる。エージェント中心のワークフローでは、コールドスタートケース、平均ケース、および深い変更ケースについて、はるかに多くのことを気にするようになる。完璧なキャッシュケースを確実に実現するために必要なエンジニアリング労力自体が、税金の一部となっている。それはますます苦痛になった。 どのように移行したか Scarfでは、新しいAPI作業はすべてPythonで行うようになった。HaskellのAPIサーバーと並行してPythonのAPIサーバーをデプロイし、リクエストを適切な場所にルーティングし、触れた機能から順次移行を開始した。新しいAPIルートはPythonに入り、既存のHaskellコードは実行され続け、時間の経過とともに新しいサーバーがメインパスになり、Haskellのフットプリントは縮小していくだろう。このアプローチにより、劇的なカットオーバーのリスクなしに移行することができた。また、認証、データベースアクセス、共有モデル、デプロイメントイメージ、テスト、運用上の接着剤など、いくつかのコア機能を再実装する必要もあった。歴史的に、そのようなセットアップ作業は高価に感じられただろう。LLMを使えば、それは悪くなかった。既存のコードを新しい言語に移植することは、今日のモデルにとって非常に簡単だ。ツールチェーンとの格闘や待ち時間から取り戻した時間は、より包括的なテストでより多くの機能をリリースするために再割り当てされた。AIは多くのテストを書くのが得意だ。ゴミや偽のテストを書く可能性があるので、まだ注意が必要だが、ループは数年前には予想できなかったほど速い。その結果を単一の指標で捉えるのは難しい。PRのスループットは明らかに増加しなかった。コミット量はノイズが多い。コード行数は悪い代理指標だ。デプロイメント数は、プレビュー、インフラストラクチャ、その他のノイズを含むため、不明瞭だ。しかし、生産性の変化は、私たちが今、高い労力で、最小限の監督で、さらには完全に自動的に出荷できるものの形状に現れている。顧客からの電話からチケット起票、PRオープン、PRレビューとイテレーション、マージ、デプロイまで、顧客との通話が終わる前にバグ修正がライブになることがある。このような生産性を妨げることはもはや選択肢ではない。 これまでのところ、切り替えで失ったものはあまりない。手放した型安全性は、特にテストカバレッジがこれまでになく向上していることを考えると、まだ具体的な形で顕著になっていない。今、バグが発生した場合、以前経験したことのないペースでホットフィックスできる。修正は文字通りSlackメッセージ一つで済むようになった。私たちのエンジニアリングチームは、生産性の向上と、活用できるテクノロジーの全く新しいフロンティアによって、より活気に満ちている。私たちは過去に必要だった開発ツールチェーンについて、大幅に少ない時間を費やしている。 Haskellエコシステムの問題 Haskellは本当の危機に瀕している。AIは定着する。それをうまく利用する人々やエコシステムは、そうでない人々やエコシステムよりもはるかに速く進むだろう。これはもはや微妙なことではないと思う。熟練したAI搭載エンジニアは、かつて数週間または数ヶ月かかっていた作業を数日でこなせるようになった。また、私がどこからこれを言っているのかを明確にしたい。私はHaskellの世界の外から石を投げつけているわけではない。私は直接関わっている。