Fable Converteu o Pylint para Rust

Projeto e Reivindicações Principais

• Reimplementação em Rust do Pylint visa:
  • Saída idêntica byte a byte ao Pylint.
  • Os mesmos bugs e mensagens de crash do Pylint.
  • Grandes ganhos de velocidade (15–2300×, mediana ~85×) em bases de código reais.

Verificação e Correção

• Vários comentaristas duvidam que a equivalência byte a byte completa seja realisticamente verificável.
• Um script de harness no repositório testa prylint vs Pylint em projetos selecionados, mas as pessoas observam:
  • Os testes cobrem apenas o comportamento observado, não todos os casos de borda.
  • Comportamento idêntico nos testes não garante comportamento idêntico globalmente, especialmente com plugins.
• Alguns veem a reivindicação de “mesmos crashes, mesmos bugs” como um sinal de cópia automática em vez de design cuidadoso.

Discussão de Desempenho

• O ganho de 2328× no destaque vem de um diretório patológico no repositório do Black envolvendo duplicate-code; isso foi depois otimizado no próprio Pylint.
• Alguns argumentam que ganhos tão grandes provavelmente refletem a correção de patologias algorítmicas que também poderiam ter sido corrigidas em Python.
• Outros respondem que grandes ganhos muitas vezes vêm da eliminação de trabalho desnecessário e que compiladores/linters estão cheios desse tipo de oportunidade.

Comparação com Ruff e Pylint

• Vários comentários: “Por que não usar apenas Ruff?”
  • Contra-argumentos:
    • Ruff ainda não cobre todos os checks do Pylint; muitos projetos executam vários linters.
    • O Pylint ainda fornece verificações mais profundas ou diferentes, importantes em ambientes mais rigorosos.
• Prylint parece reutilizar código do Ruff internamente, o que alguns criticam como reembalagem de trabalho já existente.

Confiança, Manutenção e Comunidade

• Preocupações sobre:
  • O projeto ser em grande parte gerado por LLM com mínima responsabilidade humana.
  • Manutenção de longo prazo, dado que muitos projetos passados “portados por IA” estagnaram rapidamente.
  • O risco de executar ferramentas não comprovadas e geradas automaticamente sobre código de produção.
• Outros argumentam que apenas correção e testes importam; o método de criação é secundário.

Experiência do Desenvolvedor e Fluxo de Trabalho

• Muitos consideram o Pylint atual lento demais para bases de código grandes ou hooks de pre-commit; até ~2 segundos por arquivo é visto como doloroso para trabalho interativo.
• Ferramentas mais rápidas baseadas em Rust são atraentes, especialmente para CI e para evitar interpretadores Python alternativos.

Tradução de Código Assistida por LLM e Implicações Mais Amplas

• Vários participantes descrevem ports semelhantes conduzidos por LLM (por exemplo, ferramentas Python e bibliotecas C para outras linguagens) usando “swarm” de agentes, loops automatizados de compile/test/fix e fuzzing.
• Alguns preveem:
  • Migração sistemática de linguagem para linguagem como um nicho forte para LLMs.
  • Pressão sobre projetos de código aberto, já que IA torna clonagem e reimplementação baratas.
  • Uma mudança no valor do programador, de escrever código manualmente para projetar sistemas e verificação.