HN Debrief

Fable Converted Pylint to Rust

  • AI
  • Programming
  • Developer Tools
  • Open Source

`prylint` is presented as a Rust rewrite of Pylint that aims for byte-for-byte identical output, including reproducing existing bugs and crash messages, with benchmark claims ranging from 15x to over 2000x faster. That pitch matters because Pylint is widely used in Python shops, but it is often slow enough that teams either avoid running it broadly or swap in faster tools like Ruff where they can. Several people pointed out that exact output compatibility is a sensible migration target if you want a drop-in replacement. It lets you separate “did we preserve behavior” from “did we improve the design,” which is how boring, reliable migrations are usually done.

Treat this as a proof that LLM-assisted ports can produce useful drop-in tools when the source code and test oracle already exist. Do not treat it as a durable replacement until you see real maintenance, plugin support, and benchmarks on your own workloads rather than headline numbers from edge cases.

Discussion mood

Skeptical with pockets of respect. People found the technical stunt plausible and potentially useful, but they distrusted the benchmark framing, doubted long-term maintenance, and saw more marketing than evidence of a dependable replacement.

Key insights

  1. 01

    Agentic ports need custom orchestration

    Getting a real port out of LLMs takes much more than a single prompt. The workable pattern is to chunk the source, translate pieces in parallel, merge them back together, compile, feed errors into fixer agents, then run tests and fuzzing until the failures stop. That makes this kind of project less like magic and more like building a bespoke migration pipeline around a strong verification loop.

    If you want to try this in your own codebase, budget engineering time for the harness, not just model spend. The leverage comes from automation around compile errors, tests, and review passes.

      Attribution:
    • vblanco #1
  2. 02

    The benchmark headline leans on a known worst case

    The biggest speedup appears to come from Pylint's `duplicate-code` check on Black's profiling directory, which triggers an extreme slowdown. That makes the 2000x claim directionally true but commercially weak, because it says more about one pathological workload than about everyday linting performance across normal repos.

    Ask for per-rule and per-repo benchmarks before changing tools. If your team does not rely on the slow checks, the real gain may be far smaller than the headline suggests.

  3. 03

    Ruff is not a full substitute

    For teams that still depend on Pylint-specific checks, the usual advice to switch to Ruff does not close the gap. Ruff implements a lot of Pylint rules, but commenters cited missing checks, stricter enterprise style requirements, and limited customization as reasons they still need multiple linters or Pylint itself.

    Inventory the exact rules your org enforces before assuming Ruff replaces Pylint. A faster compatible engine has real value only for the checks you cannot drop.

      Attribution:
    • Leynos #1
    • vmt-man #1
    • optionalsquid #1
    • tjpnz #1
  4. 04

    Byte-for-byte parity is a migration strategy

    Matching the original tool exactly, bugs included, is not absurd theater. It is a standard way to de-risk a migration because it isolates compatibility work from later optimization and redesign, which makes failures easier to attribute and fix.

    When replacing a mature internal tool, aim for behavioral parity first if you need a drop-in rollout. Save cleanup and architecture improvements for a second phase once production behavior is pinned down.

      Attribution:
    • Leynos #1
    • Shorel #1
  5. 05

    This is one of the few AI coding tasks with a real oracle

    Source-to-source translation is unusually friendly to agents because the source code itself acts as a detailed spec and existing behavior provides a deterministic check. That does not generalize to greenfield product work, but it does explain why these conversions keep surfacing as credible LLM wins.

    Use LLMs most aggressively where you already have executable ground truth. Be much more cautious when the job is inventing requirements, architecture, or novel behavior.

      Attribution:
    • dk_sig11 #1
    • devnull3 #1

Against the grain

  1. 01

    The generated code may not be the real artifact

    If the durable asset is the translation pipeline, then worrying about the maintainability of the emitted Rust code misses the point. This treats the port more like a compiled binary that can be regenerated as upstream changes land, not like a hand-maintained fork that needs a new community around it.

    If you evaluate projects like this, look for evidence that the regeneration pipeline is robust and cheap. A reproducible pipeline changes the maintenance equation more than pretty output code does.

      Attribution:
    • baq #1 #2
  2. 02

    Teams can use LLM migrations pragmatically

    A commenter described using Fable 5 to migrate a real internal toolchain from Nix plus npm to Docker plus pnpm with very little cleanup after extensive testing. That is a narrower claim than “AI can build products,” but it is a strong example of these systems working on constrained, high-friction migration work inside a team that already knows the destination stack better than the source one.

    Look for migration tasks where your team understands the target environment and can hammer on the result. Those are better candidates than open-ended rewrites or net-new systems.

      Attribution:
    • auslegung #1
  3. 03

    A human-guided port can outperform the original design

    One commenter's Rust port of `djlint` did not just inherit Python's structure. It used LLM help to get the migration moving, then replaced a regex-heavy implementation with tokenization and AST-based passes. That shows the ceiling here is higher than faithful translation when someone knowledgeable is willing to redesign the hot paths after compatibility is established.

    Do not stop at parity if the original is structurally slow. Once the replacement is trusted, the biggest gains may come from changing the algorithm, not the language.

      Attribution:
    • thraxil #1

In plain english

agentic coding ↩
A workflow where an AI system is given tools, feedback loops, and intermediate tasks so it can iteratively make progress with limited human intervention.
AST ↩
Abstract Syntax Tree, a structured representation of source code that makes it easier to analyze or transform than raw text.
Docker ↩
A tool for packaging software and its dependencies into isolated containers that run consistently across environments.
fuzzing ↩
An automated testing technique that feeds many unexpected or random inputs into software to find crashes and bugs.
LLM ↩
Large language model, a type of AI system trained on huge amounts of text to generate human-like responses.
Nix ↩
A package manager and build system focused on reproducible environments and declarative configuration.
npm ↩
Node Package Manager, the standard package manager for JavaScript and Node.js projects.
pnpm ↩
A JavaScript package manager designed to be faster and more storage-efficient than npm.
prylint ↩
The project in this story, a Rust reimplementation of Pylint that claims output compatibility and major speedups.
Pylint ↩
A static analysis and linting tool for Python that checks code for errors, style issues, and code quality problems.
Ruff ↩
A fast Python linter and formatter written in Rust that implements many checks from other Python linting tools.
Rust ↩
A systems programming language designed for performance and memory safety, with strict compile-time checks around ownership and borrowing.

Reference links

Project and validation references

Other AI-generated or AI-assisted code projects

  • stb_image_jai
    An example of a commenter using an agent swarm to port a C library into another language with testing and fuzzing.
  • fastrender
    Mentioned as an older AI-hyped code project that appears inactive.
  • Claude's C compiler
    Cited as another AI-generated project with little recent activity.
  • Claude's C compiler issue comment
    Linked to criticize the state of moderation and maintenance on that project.
  • vinext
    Referenced as an AI-generated project that at least appears to have business relevance.
  • matrix-workers
    Given as another example of an AI-era side project that seems to have stalled.

Benchmarks and optimization references