polars VS arrow2

I am a maintainer for a dataframe interface called polars

For example with polars, the python library extensively uses named arguments, but in rust we have to use either a builder pattern or macros. The builder pattern tends to be much more verbose than the named argument equivalent. There is currently a draft PR implementing python style named arguments for some of the most common functions.

Seeing a lot of great libraries coming out with python bindings in the data world e.g delta-rs Polars. I see it growing in this space as a C++ alternative

e.g. https://github.com/pola-rs/polars/issues/8533

I have updated this issue https://github.com/pola-rs/polars/issues/8533, please kindly help to solve it. I have also sent similar issues to Pandas https://github.com/pandas-dev/pandas/issues/53249

could you open up an issue in github

https://github.com/jorgecarleitao/arrow2 https://github.com/apache/arrow-datafusion https://github.com/apache/arrow-ballista https://github.com/pola-rs/polars https://github.com/duckdb/duckdb

A new release of polars https://github.com/pola-rs/polars/releases/tag/rs-0.29.0 query engine/ DataFrame library.

One of the interesting components of Polars that I've been watching is the use of the Apache Arrow memory format, which is a standard layout for data in memory that enables processing (querying, iterating, calculating, etc) in a language agnostic way, in particular without having to copy/convert it into the local object format first. This enables cross-language data access by mmaping or transferring a single buffer, with zero [de]serialization overhead.

For some history, there's has been a bit of contention between the official arrow-rs implementation and the arrow2 implementation created by the polars team which includes some extra features that they find important. I think the current status is that everyone agrees that having two crates that implement the same standard is not ideal, and they are working to port any necessary features to the arrow-rs crate and plan on eventually switching to it and deprecating arrow2. But that's not easy.

https://github.com/apache/arrow-rs/issues/1176

https://github.com/jorgecarleitao/arrow2/pull/1476

https://github.com/jorgecarleitao/arrow2 https://github.com/apache/arrow-datafusion https://github.com/apache/arrow-ballista https://github.com/pola-rs/polars https://github.com/duckdb/duckdb

Currently datafusion and polars aren't directly operable iirc because they use different underlying arrows implementations, but there seems to be work being done on that here https://github.com/jorgecarleitao/arrow2/issues/1429

[arrow2](https://github.com/jorgecarleitao/arrow2) and [parquet2](https://github.com/jorgecarleitao/parquet2) are great foundational libraries for and DataFrame libs in Rust.

[1] https://github.com/jorgecarleitao/arrow2

In lockstep with arrow2's 0.13 release, we have published polars 0.23.0.

This is so freaking life-saving! - we have been using StreamingIterator and FallibleStreamingIterator in libraries (arrow2 and parquet2) and the existing landscape is quite confusing for new users!

In lockstep with a new release of arrow2: https://github.com/jorgecarleitao/arrow2/releases/tag/v0.12.0