Deprecate like you mean it

Reaction to the article’s proposal (random wrong results)

• Overwhelming consensus that intentionally returning wrong or intermittent results from deprecated APIs is “profoundly awful,” unethical, and indistinguishable from sabotage.
• Main objection: it creates flappy, non-deterministic bugs that are the hardest to debug and destroys confidence in CI and systems.
• Several commenters say if you want to break an API, do it explicitly and predictably, not via hidden behavior changes.
• Many initially missed that the article was sarcastic; the author later added a clarifying note that “it’s better to leave the warts,” and that warnings are weak but intentional breakage is worse.

What people consider good deprecation practice

• Use clear timelines and channels: deprecate with warnings, publish dates/versions for removal, then remove.
• Prefer breaking changes only in major versions (true SemVer) and avoid breaking in minor releases, especially in core libs like urllib, NumPy, etc.
• Suggested flows:
  • Warnings → compiler/linter warnings → compiler/linter errors with trivial escape hatch → full removal.
  • Hard errors with explicit, ugly config/env flags to temporarily re-enable deprecated behavior.
• Strong dislike for “permanent deprecation” without ever removing, but also for projects that threaten deprecation then never follow through.

Backwards compatibility vs progress

• One camp: bitrot is mostly a series of conscious backward-incompatible changes; old software “should” still run; API churn is negative value and should be extremely rare.
• Other camp: some breakage is necessary for security, maintainability, or performance; Windows, Python 2→3, .NET, Java, etc., show that trade-offs are inevitable.
• Disagreement over whether all progress can preserve backward compatibility; some claim yes in principle, others call that naïve.

Static typing, tooling, and incentives

• Argument that static typing and easy refactoring can encourage maintainers to introduce breaking changes (“it was trivial for me, so it’s trivial for users”).
• Counter-argument: static typing helps enforce contracts and detect breakages earlier; the real issues are culture and project philosophy, not typing.
• Several note that tools and warnings exist, but many teams ignore warnings and don’t pin dependencies, effectively choosing to absorb breakages.

Alternative pressure mechanisms

• Proposed—but controversial—ideas:
  • Gradually adding latency (sleep) to deprecated paths, sometimes exponentially, to create a business incentive to migrate.
  • Brownouts (temporary, clearly messaged outages) or HTTP 426-style hard failures with upgrade instructions.
  • Charging for legacy API support or offering paid contracts/LTS instead of silent rug-pulls.

Ethics and user expectations

• Strong view that published APIs are implicit long-term promises; users reasonably expect them to keep working.
• Others stress that contracts and costs matter: nothing can be supported forever, but termination should be explicit, predictable, and clearly communicated.