Fable convirtió Pylint a Rust

Artículo original ↗ Discusión en Hacker News ↗

Proyecto y afirmaciones centrales

  • La reimplementación de Pylint en Rust apunta a:
    • Una salida idéntica byte a byte a Pylint.
    • Los mismos bugs y mensajes de fallo que Pylint.
    • Aceleraciones muy grandes (15–2300×, mediana ~85×) en bases de código reales.

Verificación y corrección

  • Varios comentaristas dudan de que una equivalencia byte a byte completa sea verificable de forma realista.
  • Un script de harness en el repositorio prueba prylint frente a Pylint en proyectos seleccionados, pero la gente señala:
    • Las pruebas solo cubren el comportamiento observado, no todos los casos límite.
    • Un comportamiento idéntico en las pruebas no garantiza un comportamiento idéntico en general, especialmente con plugins.
  • Algunos ven la afirmación de “mismos fallos, mismos bugs” como una señal de copia automática más que de diseño cuidadoso.

Discusión sobre rendimiento

  • La mejora de 2328× que aparece en el titular proviene de un directorio patológico en el repositorio de Black relacionado con duplicate-code; esto luego fue optimizado en el propio Pylint.
  • Algunos sostienen que aceleraciones tan enormes probablemente reflejan la corrección de patologías algorítmicas que también podrían haberse corregido en Python.
  • Otros responden que las mejoras importantes a menudo vienen de eliminar trabajo innecesario y que los compiladores/lintadores están llenos de esas oportunidades.

Comparación con Ruff y Pylint

  • Varios comentarios: “¿Por qué no usar simplemente Ruff?”
    • Contraargumentos:
      • Ruff aún no cubre todas las comprobaciones de Pylint; muchos proyectos ejecutan varios linters.
      • Pylint sigue ofreciendo comprobaciones más profundas o diferentes, importantes en entornos más estrictos.
  • Prylint parece reutilizar internamente el código de Ruff, algo que algunos critican como reempaquetar trabajo existente.

Confianza, mantenimiento y comunidad

  • Preocupaciones sobre:
    • Que el proyecto esté generado en gran parte por LLM con poca propiedad humana.
    • El mantenimiento a largo plazo, dado que muchos proyectos “portados por IA” del pasado se estancaron rápidamente.
    • El riesgo de ejecutar herramientas auto-generadas y no probadas sobre código de producción.
  • Otros argumentan que solo importan la corrección y las pruebas; el método de creación es secundario.

Experiencia de desarrollo y flujo de trabajo

  • Muchos encuentran que Pylint es demasiado lento para bases de código grandes o hooks de pre-commit; incluso ~2 segundos por archivo se considera doloroso para el trabajo interactivo.
  • Las herramientas más rápidas basadas en Rust resultan atractivas, especialmente para CI y para evitar intérpretes alternativos de Python.

Traducción de código asistida por LLM e implicaciones más amplias

  • Varios participantes describen ports similares impulsados por LLM (por ejemplo, herramientas de Python y bibliotecas C a otros lenguajes) usando “swarms” de agentes, bucles automáticos de compilar/probar/arreglar y fuzzing.
  • Algunos prevén:
    • La migración sistemática de un lenguaje a otro como un nicho fuerte para los LLM.
    • Presión sobre los proyectos de código abierto, ya que la IA hace barato clonar y reimplementar.
    • Un cambio en el valor del programador, de escribir código a mano a diseñar sistemas y verificación.