I use es-toolkit. It is fully in Typescript. Every function can be imported without any extra overhead, for simple functions it just adds a few bytes then to the bundle.
I doubt "better performance" since most helpers functions are just tiny and there is no room for significant improvements.
So I think trying to be better here is pointless, better focus on offering more helpful utility functions which might be missing in es-toolkit
Thanks! I'm aware of those great projects. Fahmatrix aims to offer a lightweight, dependency-free alternative that’s easy to embed in any Java app. DuckDB is super impressive, especially for SQL-heavy tasks — but my goal is more about a native, fluent API for those who prefer direct Java code over SQL.
Yes. It has bothered me for a long time too. Maybe the best mix is a dataframe library with basic operations (column select, non-null etc), which also allows SQL for more complex stuff?
Totally agree that SQL can be the best tool for many jobs. My goal with Fahmatrix is to serve the opposite niche: where devs want something that's Java-native, procedural, and simple without reaching for an external engine. SQL support or DSL might come later though — I see the appeal.
That's not it. This only exports the table's data, not the database. You lose the index, comments, schemas, partitioning, etc... The whole point of OP's article is how to export the indices in an efficient way.
Also I wonder how big your test database is and it's schema. For large tables Parquet is way more efficient than a 20% reduction.
If there's UUIDs, they're 36 bits each in text mode and 16 bits as binary in Parquet. And then if they repeat you can use a dictionary in your Parquet to save the 16 bits only once.
It's also worth trying to use brotli instead of zstd if small files is your goal.
I didn't use Timefold but the predecessor Optaplanner, and I remember there were hard constraints which must always be true (eg one room can only be used for one meeting at a given time) and then there were soft constraints which were minimized (eg shorter distance is better)
so an optimization problem can then be described with a set of those hard/soft contraints
Yes!
These days, to handle cases with more work than resources to do it, medium constraints are used a lot too (so hard/medium/soft constaints), to penalize the amount of unassigned work. Those are harder than soft constraints, but softer than hard constraints.
So I think trying to be better here is pointless, better focus on offering more helpful utility functions which might be missing in es-toolkit
reply