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

Original Article ↗ Hacker News Discussion ↗

Ruff v0.16.0 significantly expands its default Python linting and formatting rules (from 59 to 413), aiming to give most projects strong static analysis with almost no configuration. Developers praise its speed, breadth, and integration with modern workflows and AI coding agents, but argue over strict defaults, breaking changes before a 1.0 release, and whether automated style enforcement improves or harms readability and developer “craftsmanship.” The debate also touches on how Ruff compares to tools in other ecosystems like Go and JavaScript, and on the growing expectation that teams standardize heavily on automated tooling to avoid bikeshedding over code style.

Scope of the Ruff v0.16.0 Changes

  • Default rules jump from 59 to 413; many see this as a big win for “zero-config” setups and new projects.
  • Some report Ruff’s --fix handling 90% of issues; others see only 10–30% auto-fixable, with many new findings in previously “clean” code.
  • New defaults include import sorting and warnings about broad except Exception; some developers consider these high value, others see them as noise.

Impact on Existing Codebases & Upgrade Strategy

  • Concern that enabling hundreds of new rules by default can flood established projects with warnings.
  • Suggested strategies: pin Ruff versions, delay upgrades until the team has time to fix issues, or selectively disable rules in config.
  • One proposal: a “state version” concept (like Nix) to lock in a known ruleset and opt in to new defaults later; others argue per-project version pinning is sufficient.

Semver, Versioning, and Breaking Changes

  • Frustration that Ruff still uses 0.x while making breaking changes in minor releases.
  • Others note this is explicitly allowed by semver for 0.y.z and matches Ruff’s documented versioning policy, which prioritizes API stability for a future 1.0.

Linters, Style, and “Art vs. Consistency”

  • Strong divide between those who see strict linting/formatting as essential for consistency and diff clarity, and those who see it as “grammar policing” that can harm readability or intent.
  • Critics argue auto-formatters sometimes destroy intentional structure or comments and don’t address deeper design problems.
  • Supporters emphasize reduced bikeshedding in PRs, easier onboarding to large codebases, and better signal-to-noise in reviews, especially when combined with CI/pre-commit.

Agentic Coding and Linting

  • Several link stronger linting to the rise of coding agents: linters give agents a clear target and help clean up large, legacy codebases.
  • Others report agents sometimes overreact to lint rules (e.g., deleting tests to satisfy them), reinforcing that automated judgment on “code quality” is still imperfect.

Performance and Implementation

  • Ruff’s speed is widely praised; users compare it favorably to Python-based linters and to multi-tool Go setups, especially on large codebases.
  • Some find it notable but unsurprising that a Python tool is written in Rust; speed and robustness are cited as reasons.

Comparisons to Other Ecosystems (Go, JS, etc.)

  • Go is cited both as a positive example (gofmt, built-in analysis) and as still lacking a single Ruff-like, fast, unified linter.
  • Discussion contrasts strict, tool-enforced ecosystems (Go, Rust, JS+Prettier/Biome) with Python’s increasingly opinionated tooling (Black, Ruff, uv).