Polars

Artigo original ↗ Discussão no Hacker News ↗

Polars, uma biblioteca de DataFrame rápida escrita em Rust com bindings para Python e outras linguagens, está chamando atenção como um possível sucessor do pandas para análise tabular em memória. Comentadores destacam grandes ganhos de velocidade e memória em conjuntos de dados grandes, uma API lazy mais consistente e parecida com SQL, além de integração estreita com Arrow e ferramentas como o DuckDB, ao mesmo tempo em que apontam trade-offs como suporte a GPU e distribuído ainda imaturo, mudanças frequentes e incompatíveis e menor compatibilidade com o ecossistema em comparação ao pandas. Muitos o veem como ideal para novos workloads críticos de desempenho, mas recomendam adoção cautelosa em codebases existentes, fortemente dependentes de pandas.

O que é o Polars

  • Biblioteca de DataFrame colunar escrita em Rust, exposta para Python, JS, Rust, R, Elixir, Ruby.
  • Construída sobre Apache Arrow com um mecanismo de consulta em estilo OLAP e execução lazy opcional.
  • Voltada para análise em memória em máquina única; ainda não há execução distribuída nem em GPU.

Desempenho vs Pandas (e Outros)

  • Muitos relatos de acelerações de uma ordem de grandeza em relação ao pandas (por exemplo, ~1 minuto → ~1 segundo) para groupbys, joins e scans em conjuntos de dados de vários GB ou com 10M+ linhas.
  • Principais vantagens citadas: implementação em Rust, multi-threading, planejamento de consultas lazy, menor uso de memória e interoperabilidade com Arrow.
  • Para conjuntos de dados pequenos (≤100k linhas), usuários dizem que as diferenças de desempenho raramente são perceptíveis para humanos.
  • Benchmarks mencionados: o db-benchmark do DuckDB mostra Polars e DuckDB muito à frente do pandas; alguns observam que o DuckDB pode ser mais rápido que o Polars em muitas cargas de trabalho.
  • Ferramentas out-of-core / distribuídas (Spark, Dask, Modin, Vaex, RAPIDS) são vistas como uma categoria diferente; pessoas alertam que incluí-las em benchmarks de nó único é um pouco enganoso.

API, Ergonomia e Ecossistema

  • Muitos acham a API do Polars mais consistente, parecida com SQL e mais fácil de raciocinar do que a do pandas; encadeamento de expressões e dataframes lazy são elogiados.
  • Outros a consideram mais verbosa, especialmente para operações linha a linha (“axis=1”) ou transversais e transformações complexas.
  • Forte interoperabilidade: troca zero-copy fácil com pandas/DuckDB via Arrow; um padrão comum é “Polars para o trabalho pesado, pandas nas bordas”.
  • Alguns reclamam que bibliotecas-chave de DS (por exemplo, scikit-learn, ferramentas de plotagem) ainda são centradas em pandas, forçando conversões.

Docs, Onboarding e Marketing

  • A landing page é criticada por assumir conhecimento de “DataFrames” e por enfatizar velocidade em vez de dizer claramente “o que é” e quais são os casos de uso.
  • A separação entre “User Guide” e “Docs” confunde alguns; outros acham a documentação sólida e apreciam a API limpa.
  • Um livro dedicado ao Polars e um guia oficial do usuário estão previstos; o Discord é usado para suporte, com preocupações de que o conhecimento fique preso no chat.

Estabilidade, Adoção e Ferramentas

  • O status pré-1.0 e as mudanças frequentes e incompatíveis fazem algumas equipes hesitarem em migrar grandes codebases; outras o usam em produção com satisfação e aceitam atualizações trimestrais.
  • Os bindings para JS são descritos como promissores, mas ainda bugados/imaturo.
  • GitHub Copilot e ferramentas semelhantes funcionam muito melhor com pandas; alguns usuários continuam no pandas principalmente pelo suporte de assistentes de IA, enquanto outros argumentam que a escolha da ferramenta não deveria ser guiada por isso.

Reflexões Mais Amplas

  • Debate sobre se só a velocidade justifica a troca, em vez de clareza e ecossistema.
  • Alguns veem o Polars como “pandas, mas rápido” e um provável sucessor de longo prazo; outros preferem mecanismos SQL (DuckDB, Postgres) ou abordagens que não usam DataFrame de forma alguma.