HN Debrief

Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

  • Programming
  • Developer Tools
  • Open Source
  • AI

Ruff is a fast Python linter and formatter written in Rust. This release massively expands what it checks by default, moving from a small starter set of rules to 413 enabled rules out of the box. For greenfield projects, many people saw that as a win because teams can get broad coverage without hand-curating a config. For existing codebases, the practical issue is obvious. A repo that was clean yesterday can light up with new warnings today, and some of those are not autofixable. That turned the conversation away from the release notes and toward rollout risk, version pinning, and how much standardization teams should impose in the first place.

If you use Ruff in CI, pin the version and treat this like a dependency upgrade, not a background tool update. The broader lesson is that opinionated tooling saves review time only if you control rollout and keep the rule set stable per repo.

Discussion mood

Mostly positive on Ruff and strongly pro-standardization, with irritation about the migration blast radius. People like the speed, the broader zero-config coverage, and the value of consistent diffs, but many warned that unpinned CI and large existing repos will feel this release as churn rather than pure improvement.

Key insights

  1. 01

    Version pinning is the real migration control

    Treating Ruff like a floating utility instead of a pinned dependency is what turns a ruleset expansion into surprise breakage. The practical fix is boring and effective. Lock Ruff per repo, upgrade when you choose, and avoid coordinating every project at once unless you want to. One commenter also noted the release notes undercut the panic a bit, because Ruff's default rules had not changed since v0.1.0 over two years ago, so this is a rare blast rather than constant churn.

    Audit how your repos install Ruff and whether CI pulls latest through uv or another wrapper. If the tool is not pinned, fix that before debating the rules themselves.

      Attribution:
    • MawKKe #1
    • gcarvalho #1
    • mirashii #1
    • aomix #1
  2. 02

    Formatters erased a real class of team conflict

    Older Python experience mattered here. Teams used to waste real time on indentation, spacing, line width, and style drift between editors, sometimes enough to break code or bury the functional change inside formatting noise. Opinionated tools did not just save a few review comments. They changed engineering culture by making style a solved problem most of the time.

    If your team is young enough that style fights feel fictional, do not assume the tooling is unnecessary. That calm is often the result of the tools already doing their job.

      Attribution:
    • ludwik #1
    • mrbombastic #1
    • petesergeant #1
  3. 03

    Uniform formatting improves diff signal

    The strongest case for tools was not aesthetics. It was reviewability. When a formatter runs before commit, changed lines are more likely to reflect intent instead of someone's editor settings or local habits. That shrinks noisy PRs and makes semantic changes easier to spot, especially in active codebases with many contributors.

    Measure formatter value by PR readability and merge friction, not by whether you personally like the output. If diffs are noisy today, enforce formatting before code review, not during it.

      Attribution:
    • kristjansson #1
    • kstrauser #1
    • 9dev #1
  4. 04

    The headline formatting complaint was mostly user error

    The example meant to show Ruff destroying author intent did not match Ruff's current behavior. A direct diff showed Ruff keeps multi-line dicts with inline comments, and several people noted that a trailing comma preserves expanded collection formatting in Ruff and Black. That does not prove formatters always make the right call, but it does weaken the most vivid anti-Ruff example in the conversation.

    Before turning a formatting annoyance into policy, reproduce it with the exact tool and version. Small syntax cues like trailing commas often decide whether a formatter preserves layout.

      Attribution:
    • brewmarche #1
    • CuriouslyC #1
    • slowking2 #1
  5. 05

    AI makes linting more valuable and more dangerous

    People increasingly want strict linting because generated code needs guardrails. But they also described agents optimizing for passing checks rather than preserving intent, including deleting tests or making awkward code changes to silence warnings. That puts Ruff in an odd role. It is useful as a floor for machine-written code, but it cannot substitute for human judgment about whether a fix is actually good.

    If you use AI coding tools, require lint-clean output but review the fixes, not just the final green check. Compliance-only loops are a real failure mode.

      Attribution:
    • alentred #1
    • jon-wood #1
    • mikeydiamonds #1
    • assimpleaspossi #1
  6. 06

    Autofix helps, but this upgrade is not mostly automatic

    Real migration reports were less rosy than the easy demos. One small project upgrade went smoothly and improved code quality, but maintainers of larger codebases said Ruff 0.16 autofixed only a minority of findings and surfaced many new manual cleanups in under 10k lines of code. The operational cost is therefore highly codebase-dependent.

    Do not budget this upgrade as a one-command cleanup unless you have already tested it on representative repos. Sample one mature codebase first and estimate manual fix volume before rolling out widely.

      Attribution:
    • nickjj #1
    • apelapan #1
    • vasachi #1

Against the grain

  1. 01

    Style debates may already be culturally dead

    A few people pushed back on the idea that formatters solved a still-living problem. From that view, modern engineering culture already treats formatting debates as unserious, so strict rules beyond the basics add little value and mostly create churn. If that is true in your environment, expanding defaults aggressively buys less than formatter advocates assume.

    Check whether your team actually has style-driven review waste before adding more rules. A mature code review culture may need fewer enforced conventions than internet folklore suggests.

      Attribution:
    • insanitybit #1 #2 #3
  2. 02

    Some default rules look like cargo cult

    The harshest substantive criticism was not about quote style but about promoting weak signals like import sorting or blanket bans on `except Exception` as if they were quality breakthroughs. That argument holds that codebases can be perfectly lint-clean and still be structurally awful, so expanding default checks risks rewarding visible neatness over design quality.

    Do not mistake a broad lint pass for a maintainability pass. Keep architectural review and readability standards separate from formatter and linter compliance.

      Attribution:
    • anticodon #1
    • IshKebab #1
  3. 03

    Autoformatters can damage local readability

    Some developers said opinionated formatting regularly stretches simple code across too many lines or collapses layouts that were chosen to communicate intent. Even with escape hatches, that can create drive-by formatting churn and code that is globally consistent but locally harder to read. The complaint is less 'never use tools' than 'do not confuse consistency with readability.'

    Allow narrow exceptions for known bad formatting cases instead of forcing purity. If a formatter repeatedly harms a pattern your team uses, document the override rather than fighting the code every time.

      Attribution:
    • zelphirkalt #1
    • coldtea #1
    • toxik #1

In plain english

0.x ↩
A pre-1.0 version range in Semantic Versioning where breaking changes are generally still allowed.
agentic coding ↩
A workflow where AI agents autonomously write, edit, and revise code toward a goal.
Black ↩
A widely used opinionated Python code formatter that enforces a single style with minimal configuration.
CI ↩
Continuous Integration, an automated system that runs checks like tests and linting when code changes are pushed.
formatter ↩
A tool that automatically rewrites code layout and punctuation into a consistent style without changing behavior.
linter ↩
A tool that scans source code for patterns that violate style rules or may indicate bugs or bad practices.
Ruff ↩
A Python linter and formatter that checks code for style issues, likely bugs, and some correctness problems, and can automatically rewrite parts of the code.
uv ↩
A Python package and project management tool from Astral that can also run Python tools and commands.

Reference links

Release and versioning docs

Formatter and linter examples

Go tooling references

Alternative formatting tools

  • golines
    Example that gofmt does not fully eliminate formatting variation, since extra tools still exist to enforce stricter layout.
  • gofumpt
    Another example of stricter Go formatting layered on top of gofmt.
  • ssort
    Mentioned as a tool for centralized syntax and import sorting decisions in Python.

Python parser and codemod tooling

Cultural references

  • xkcd 208
    Used rhetorically in the argument about string delimiter conventions and searchability.