GCとかロケット科学すぎてウェブサービス屋さんには似合わない

※タイトルは釣りです。

先のエントリで、

採るべき技術的アプローチに関しては、ソフトウェアの修正コストによってかわるという議論があって、ウェブサービスの場合にはソフトウェア製品(やSI)と比べて圧倒的に修正コストが安い。ウェブサービスの場合にロケット科学的な「正しいけど大げさ」なアプローチよりも、小さく作って動かしながら修正していく手法が好まれるのにはそういう背景もある

ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場

と書いた件、GCを例にあげて説明します。

ソフトウェアを製品として出荷するビジネスは、修正コストが高いです*1。企業向けソフトウェアなら、管理者がアップデートをインストールしなけりゃいけないし、それによって不具合が発生していないか結合試験が必要になるかもしれないし、場合によって南極まで出張して…ごにょごにょ。

こういうビジネスにおいては、そもそもバグを出さない仕組みが重要になります。GCとかいいですね。循環参照でメモリリークが出る参照カウントとかクソですね。そんなバグ、いちいち修正してはリリースしてたら、お客さんからそっぽ向かれますね。

でも、ウェブサービス屋さんにとっては違うんです。参照カウントのほうが使いやすかったりする。突然の停止とかないし、パフォーマンス予測できるし、メモリリークがあったら運用で対処したっていいし、問題になる所だけ、問題になる度に修正していけばいい。

以上、たとえばということでGCを例にあげてみました*2。っていうか、某GC屋さんたち、叩かれすぎでかわいそうだと思う。すごくいい仕事してると思うんですけどね。

ちなみに僕は今、ゲーム業界に身をおいているので、停止時間が予測しやすいCopy GCが好きです。

*1:ここでいうコストとは、バグを修正するコストだけではなく、実際にその修正を適用する作業も含む

*2:例えば、言語処理系を選択する際にはGC方式は検討要素のひとつでしかありません。GCを使うソフトウェアを避けるべきと一概に主張しているわけではありません