IDEなどの開発支援機能を使用できない場合が少なくない .chsファイルへの非対応

実際的な広いユースケースで現代的なプログラミングを実現できておらずインタラクティビティの低い原始的なプログラミングを強いられる ビルドが長すぎる(1時間前後) 脆弱性修正の数分以内の緊急デプロイといったセキュリティ要件を満たさない

ダウンタイムがビルド時間に応じて長時間化することで繁忙期などに発生した重大問題が甚大な機会損失および信用失墜に発展するリスクが非常に高い

アップデートやデバッグなどにともなう長時間のリビルドによる人員設備等の稼働率低下による損失が大きすぎる

勤怠状況の不明瞭化による勤怠管理の困難化が怠業を誘発し周辺人員への悪影響などの周辺問題の連鎖的発生と拡大につながる構造的問題が生じる レコードフィールド名に非現実的な制約がある 外部スキーマとの互換性の問題が不可避的

ソースコードのエントロピーがフィールド名に限って悪化する

以上の理由からサービス開発へのHaskellの使用を放棄した。

Haskellは以前はプロダクションレディだったかもしれないが今は少なくともサービス開発においてはそうではない。一度プロダクションレディになれば永遠にプロダクションレディでいられるわけではない。実用言語であり続けるためにはプログラミングの進歩とこれにともなう要件の変化に継続的に追従する必要がある。

補足

当然ながらコンテナOSで実行するためスタティックリンクが必須となる。 オプションを変えてテストする成果物とデプロイする成果物を変えるなど論外。 CIサーバーのキャッシュは小規模な実験的プロジェクトでも簡単に数ＧＢに達してあふれるので無意味。 キャッシュできたとしても依存関係やStackのアプデごとに1時間かけて再構成しなければならず変化に極めて脆弱で気休め程度にしかならない。 ローカルビルドとリモートビルドに1時間ずつかかるような試行錯誤が困難で触りたくないと思われるコードベースや開発環境のプロダクトは死んだプロダクトだということを念頭に置かなければならない。