Tables.jl vs TableTraits.jl (was TextParse.jl is fast again)

[leethargo]

As an outside observer to this discussion and user “in the market” for an ecosystem of tabular datastructurs, my understanding of the different between the camps could be summarized as:

• Queryverse.jl/TableTraints.jl: Focus on interop first (support many packages with simple interface), worry about performance in special cases later.
• Tables.jl: Focus on performance first (define richer interface for different use cases: row-based/col-based), support fewer packages (now, because starting from scratch)

Not sure if this description is accurate or helpful, but I guess this discussion would be most productive if all the contributors agree on the strengths of their respective approaches.

Also, I guess it would be possible to implement interface bridges between the two, but of course this work would be redundant if one could agree on a single interface in the first place.

[Tamas_Papp]

I am also an outsider to both projects, but intrinsically, I don’t think there is anything that prevents either design from being fully optimized.

I originally thought that Tables.jl was a simpler framework than TableTraits.jl, but I am no longer sure that using Julia’s iteration protocol directly for access is able to handle everything well (eg resource management, cf #22466).

I think that ultimately an ideal interface will require a departure from iterate.