Polars

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

Polars, una biblioteca DataFrame rápida escrita en Rust con bindings para Python y otros lenguajes, está atrayendo atención como posible sucesora de pandas para el análisis tabular en memoria. Los comentaristas destacan grandes ventajas de velocidad y memoria en conjuntos de datos grandes, una API lazy más consistente y parecida a SQL, y una integración estrecha con Arrow y herramientas como DuckDB, aunque también señalan compensaciones como soporte inmaduro para GPU y sistemas distribuidos, cambios rompientes frecuentes y menor compatibilidad con el ecosistema frente a pandas. Muchos la ven ideal para nuevas cargas de trabajo críticas en rendimiento, pero recomiendan una adopción cautelosa en bases de código existentes muy centradas en pandas.

Qué es Polars

  • Biblioteca Columnar DataFrame escrita en Rust, expuesta a Python, JS, Rust, R, Elixir y Ruby.
  • Construida sobre Apache Arrow con un motor de consultas estilo OLAP y ejecución diferida opcional.
  • Apunta a análisis en memoria en una sola máquina; todavía no tiene ejecución distribuida ni en GPU.

Rendimiento frente a Pandas (y otros)

  • Muchos informes hablan de mejoras de velocidad de orden de magnitud sobre pandas (por ejemplo, ~1 minuto → ~1 segundo) para groupbys, joins y scans en conjuntos de datos de varios GB o de más de 10M de filas.
  • Ventajas clave citadas: implementación en Rust, multi-threading, planificación de consultas diferida, menor uso de memoria e interoperabilidad con Arrow.
  • Para conjuntos de datos pequeños (≤100k filas), los usuarios dicen que las diferencias de rendimiento rara vez son perceptibles para una persona.
  • Benchmarks mencionados: el db-benchmark de DuckDB sitúa a Polars y DuckDB muy por delante de pandas; algunos señalan que DuckDB puede ser más rápido que Polars para muchas cargas de trabajo.
  • Las herramientas out-of-core / distribuidas (Spark, Dask, Modin, Vaex, RAPIDS) se ven como una categoría distinta; la gente advierte que incluirlas en benchmarks de un solo nodo es algo engañoso.

API, ergonomía y ecosistema

  • Muchos consideran que la API de Polars es más consistente, más parecida a SQL y más fácil de razonar que pandas; se elogian el encadenamiento de expresiones y los dataframes diferidos.
  • Otros la encuentran más verbosa, especialmente para operaciones por filas (“axis=1”) o transversales y transformaciones complejas.
  • Fuerte interoperabilidad: intercambio fácil y sin copia con pandas/DuckDB vía Arrow; un patrón común es “Polars para el trabajo pesado, pandas en los bordes”.
  • Algunos se quejan de que bibliotecas clave de DS (por ejemplo, scikit-learn, herramientas de gráficos) siguen estando centradas en pandas, lo que obliga a convertir datos.

Documentación, incorporación y marketing

  • La landing page recibe críticas por asumir conocimiento de “DataFrames” y por enfatizar la velocidad en lugar de explicar claramente “qué es” y sus casos de uso.
  • La división entre “User Guide” y “Docs” confunde a algunos; otros encuentran la documentación sólida y aprecian la API limpia.
  • Se menciona un próximo libro dedicado a Polars y una guía oficial del usuario; Discord se usa para soporte, con preocupaciones de que el conocimiento quede atrapado en el chat.

Estabilidad, adopción y tooling

  • El estado pre-1.0 y los cambios rompientes frecuentes hacen que algunos equipos duden en migrar grandes bases de código; otros lo usan felizmente en producción y aceptan actualizaciones trimestrales.
  • Las bindings para JS se describen como prometedoras pero todavía con errores/inmaduras.
  • GitHub Copilot y herramientas similares funcionan mucho mejor con pandas; unos pocos usuarios se quedan con pandas principalmente por el soporte de asistentes de IA, mientras que otros argumentan que la elección de herramienta no debería depender de eso.

Reflexiones más amplias

  • Debate sobre si la velocidad por sí sola justifica el cambio frente a la claridad y el ecosistema.
  • Algunos ven Polars como “pandas pero rápido” y un probable sucesor a largo plazo; otros prefieren motores SQL (DuckDB, Postgres) o enfoques que no sean de dataframe en absoluto.