arrow2 VS case-studies

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!

arrow2 has support for mssql via ODBC (which microsoft has first class support to). Here are the integration tests we have (both read and write) against mssql specifically.

Luckily there is a workaround to emulate such a definition, which dtolnay discovered and explained here: https://github.com/dtolnay/case-studies/tree/b9802f6df8dc8e54970b83fb9af6df923b46abf5/unit-type-parameters.

I think they are talking about this one trick which the devs don't want you to know about. Note that while it looks like specialization, it works only in a few very limited cases and is quite fragile, so it's a hack, not a substitute for the real feature.

Also I suggest his case studies repo since you are looking at what is possible: https://github.com/dtolnay/case-studies

/u/dtolnay has a great case studies repository.

Once you have the basics down, read dtolnay's case studies. They show how to do advanced stuff with easy macros.

If you were writing your own println macro, you might be able to get away with this kind of hack: https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md

You can use "Autoref-based stable specialization" or use/mimic the impls crate.

With a subset of specialization likely riding the trains soon and a workaround available, why would you give up?

this works since values and types are in different namespaces (see: Rusts Universes or dtolnay's Case Study about "Unit struct with type parameters")

To do this with traits you would need specialization but since you are using macros you should be able to use "Autoref-based stable specialization". Here is a playground which uses the latter approach to implement the wanted macro without using any nightly features.