So We've Got a Memory Leak

PHP, shipping, and security trade‑offs

• Debate over PHP’s “just ship it” origins: some see quick delivery and massive adoption as proof the trade-offs (weak testing, security issues) were correct.
• Others argue popularity doesn’t excuse negligence around tests, cryptography, or backward‑compatible “half‑fixes” (e.g., confusing APIs like mysql_real_escape_string).
• Disagreement over whether market success validates technical decisions or simply reflects short‑term incentives.

“Never free” and restart‑based strategies

• Some note that never calling free() (or relying on process exit) can be valid when process lifetime is well‑bounded (CGI, short‑running tools).
• Others warn this becomes unmanageable in long‑lived services or when code is later reused as a library.
• Examples: Apache’s pool allocator, Git’s process‑lifetime allocations, ad servers and web apps using periodic restarts to mask leaks.

Manual vs automatic memory management

• Pro‑manual side: with RAII, clear ownership rules, and discipline, manual management is seen as straightforward and less opaque than reference counting or GC.
• Counterpoint: real‑world data (many security bugs from use‑after‑free) shows humans are bad at this at scale; memory‑safe languages reduce entire bug classes.
• Some argue that leaks and “unintentional object retention” still exist with GC, just in different forms.

GC, performance, and language design

• GC praised for largely eliminating memory errors in typical projects, though object‑graph leaks and performance regressions remain issues.
• Others report profiles where GC dominates runtime and cite large speedups when GC is disabled, arguing overhead is often “horrific.”
• Discussion of alternatives: arenas, custom allocators, Rust‑style ownership, Zig’s allocator‑passing model, RAII in C++/Rust, and defer/using/context managers as partial RAII substitutes.

Tools and debugging practices

• Valgrind, Coverity, fuzzing, and error‑injection are cited as effective for finding leaks and error‑path bugs.
• Static analyzers can conflict with deliberate “no free” strategies, leading to refactors and potential new bugs.

Human and organizational factors

• Several comments stress that memory management increases cognitive load; many developers can’t reliably handle it on large, complex systems.
• GC and ownership systems are framed as ways to offload that burden, especially in big teams with varied skill levels.