こんな本が早々にゴミにされるなんて皮肉だね。

Q: この現実の例はどんなコレクションを示してるの？ A: コピーガベージコレクタ（セミスペース）。第4章！素晴らしい本だよ。ベイカーのトレッドミルにはいつも魅了されてた。フィボナッチサイズのミルで実装できる現実のケースが欲しかったんだ。

CodexやClaudeが手動メモリ管理を間違えたのを見たことがない。自分のメモリ管理の問題をキャッチするためにリークサニタイザーや他のツールを使うのにかなりこだわってたけど、今はLLMに頼るようになって、その手のテストは心配のリストの下の方に落ちてきた。以前は面倒だったりエラーが起きやすかったタスクが、もうそうじゃなくなったことに驚いてる。C++のような中間安全な言語から、Rustのようなもっと安全な言語だけじゃなくて、意外にもCやプラットフォーム特有のアセンブリのような、あまり安全でない言語にシフトするのを期待してるよ。

僕の意見では、1964年末にIBMのPL/Iプログラミング言語によって導入された「手動」のメモリ管理は、Cや他の言語に受け継がれたもので、プログラマーが「free」を呼び出す責任を持つっていうのは、深刻な間違いだったと思う。導入された時点で既に時代遅れの技術だったんだ。明示的な「free」が発明されたときには、自動メモリ再利用の方法が1960年から4年間知られていて、別のIBMの社員が参照カウントを発明したんだ（LISP Iのガーベジコレクターに反応して）。単純に実装すると参照カウントにはいくつかの欠点があるけど、最適化された実装ではそれを比較的簡単に回避できる。親の記事で話題にされている本にも、参照カウントについての章があるよ。僕は何十年もCプログラムを書いてきたけど、直接「free」を呼び出したことは一度もない。常に参照カウントを使ってきたからね。直接「free」を呼び出したいと思ったこともない。Cは、コンパイラが仮想関数の呼び出しや参照カウントの処理などを暗黙的に行わないという欠点があるけど、高レベル言語が提供するような技術は、Cのような言語でも使えるよ、たとえそれがもっとボイラープレートコードを必要としたとしてもね。「shared_ptr」の参照カウントの実装は好きじゃないな。あのデータ型は、普通の参照やポインタが期待される場所では直接使えないから。そういう問題がない実装も存在するよ。

GCの強みは、書くのが簡単なだけじゃなくて、読むのも楽だってことだよ。どこでもアロケーションとビジネスロジックを交互に書く必要がないからね（型や命令型コードを通して）。GCは、実際のコードで擬似コードの明瞭さに近づく唯一の方法なんだ。これがこのテーマについての僕の後の気づきの一つだよ。 (https://world-playground-deceit.net/blog/2024/11/how-i-learn...)

Zigは結構いいけど、まだ完璧じゃないね。

Linuxカーネルにはガベージコレクションがあるよ。しかも、物議を醸す参照カウント型だけじゃない。

このシリーズの本で気に入らなかったのは、「ガーベジコレクション」という言葉をトレーシングGCと参照カウントの両方の傘用語として選んだことだね。プログラミングコミュニティがそれに同意するか確認せずにやっちゃったみたいで、結果的に同意してなかった。これはメモリ管理の研究で何十年も使われてきた標準的な用語なんだ。嫌がってるプログラマーは、メモリ管理の原則を理解してない人たちだけだよ。 > その定義だと、C++のコードはstd::shared_ptrを使ってればガーベジコレクションをしてるってことだね。そうだね。 > 「ガーベジコレクションされたプログラミング言語」という用語の一般的な使われ方に反してるのは、C++やRustのような手動の言語とガーベジコレクションされた言語を対比させるためなんだ。この対比は、メモリ管理を理解してない人たちの頭の中にしか存在しないから、この誤解に反するのはいいことだよ。でも、「ガーベジコレクション」が面白くないってわけじゃないし、興味深いトレードオフもあるよね。君が言ったように、C++とRustはGCを使ってるし、実際にCPythonで使われてるGCに似たものを使ってるんだ。

「ガーベジコレクション」の代わりに「動的ライフタイム決定」って言えるよ。コードが実行時に「このメモリを解放しても安全か？」って質問に答えるために動いてるなら、それが動的ライフタイム決定で、参照カウントとより洗練されたGCスキームの両方に共通する特性なんだ。