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

**URL:** <https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982>\
**Category:** Data\
**Created:** [October 29, 2018, 7:13pm UTC](https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982 "2018-10-29T19:13:51Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![leethargo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/leethargo/32/6004_2.png) [@leethargo](https://discourse.julialang.org/u/leethargo)\
**Post date:** [November 12, 2018, 10:29am UTC](https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982/21 "2018-11-12T10:29:52Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [November 12, 2018, 10:45am UTC](https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982/22 "2018-11-12T10:45:58Z")

</div>

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](https://github.com/JuliaLang/julia/issues/22466)).

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

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [November 22, 2018, 10:03am UTC](https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982/23 "2018-11-22T10:03:47Z")

</div>

Split this topic on November 22, 2018, 10:03am UTC

2 posts were split to a new topic: [Package for tabular data](https://discourse.julialang.org/t/package-for-tabular-data/17849)

[Previous page](https://discourse.julialang.org/t/tables-jl-vs-tabletraits-jl-was-textparse-jl-is-fast-again/16982.md?page=1)