When defining a problem, one anti-pattern is wording "doesn't have/support X" where X is actually a solution. E.g. absence of a GC in a language isn't a problem. The problem is security bugs and memory leaks, and GC is a typical solution, but not the only one - Rust solved it without a GC.

I like using the word "pain" instead, a strong word, something undeniably frustrating, potentially damaging. Absence of GC isn't pain. Crashing OOM apps and security breaches are.

@ntx Interesting. I notice the same confusion in academic software engineering discussions. There is still, to this day, no clear understanding of what a "feature" is and how it maps to functional (and non-functional) requirements.

For instance: GC is a feature of a language, but the requirement can be defined both as "We need a GC" and "We need to fix memory leaks and security bugs in a <insert adjective> way".