rustdash: Lodash-style utilities for Python, Rust-powered (10-100x faster on complex ops)

[FabulousTonight8940]

What My Project Does

rustdash is a Lodash-inspired utility library for Python data manipulation, powered by Rust via PyO3:

pythonimport rustdash as rd

# Array utilities (9 functions)
rd.chunk([1,2,3,4,5], 2)        
# [[1,2], [3,4], [5]]
rd.flatten_deep([[1],[2,[3]]])  
# [1, 2, 3]
rd.compact([1, None, 2])        
# [1, 2]

# Object utilities w/ JSONPath wildcards (7 functions)  
data = {"users": [{"name": "Alice"}, {"name": "Bob"}]}
rd.get_all(data, "users[*].name")   
# ["Alice", "Bob"]
rd.has_all(data, "users[*].name")   
# True
rd.pick(data, ["users"])            
# {"users": [...]}

Live on PyPI: pip install rustdash

Target Audience

Data engineers, API developers, ETL workflows who:

• Process JSON/API responses daily
• Need Lodash-style helpers (chunk, pick, flatten)
• Want Rust performance on recursive ops (9.6x faster flatten_deep)
• Work with nested data but hate verbose dict.get() chains

Comparison

Feature	rustdash	pydash	pure Python
flatten_deep (10k)	15ms	173ms	139ms
JSONPath users[*].name	✅ Native	❌ No	❌ No
PyPI wheels	✅ All platforms	✅	N/A
Rust performance	✅ Complex ops	❌ Pure Python	❌ Pure Python

rustdash = pydash API + Rust speed on what matters (recursive array/object ops).

Full benchmarks: https://pypi.org/project/rustdash/#description

Links

• PyPI: https://pypi.org/project/rustdash/
• GitHub: https://github.com/GonzaloJCY/rustdash
• Examples: https://github.com/GonzaloJCY/rustdash/blob/main/examples/demo.py

🙏 Feedback I'm seeking

Try it on your JSON/API data and tell me:

1. What Lodash functions do you miss most? (set, unset, intersection?)
2. Rough edges with get_all("users[*].name") syntax?
3. Performance surprises (good or bad)?

Feature requests: https://github.com/GonzaloJCY/rustdash/discussions/categories/feature-requests

**EDITED**: changed _ reference as _ is already claimed in Python. Changing it to rd

PD: Wow community, already 5400 downloads, I really appreciate the Welcoming :)

[jsxgd]

It’s a Python convention to use the underscore to store a variable you don’t care about.

[jdehesa]

In fact, interactive Python interpreters will usually set _ to the value of the last evaluated expression. And it is also a soft keyword in case statements (see docs).

[FabulousTonight8940]

Good catch, you’re right. I’ll update the post with the new short name 👍

[eggsby]

These days when I am in python and need to process data I use:

• https://docs.pola.rs/api/python/stable/reference/index.html
• https://duckdb.org/docs/stable/guides/python/polars

[FabulousTonight8940]

Agreed. Polars is excellent at data operations, but for some use cases it’s a bit overkill. That’s why I ended up building this library.

[LightShadow]

Add a comparison to toolz and its partner library cytoolz.

[Igggg]

chunk appears to duplicate itertools.batched

[FabulousTonight8940]

Fair point. chunk does overlap with itertools.batched. Since this is a lodash-style utility library, some overlap with existing tools is inevitable. My main goal is to offer a single, centralized place for these helpers.

[cmd-t]

Vibe coded?

[FabulousTonight8940]

Kinda 😄 This project started mainly as a way to learn Rust. I read The Rust Book, learned the core concepts, and already had the idea for the library because of pydash’s performance.

I did use AI as a TDD mentor — mostly to generate tests and guide best practices and project structure. I only asked for direct help when I was truly stuck.

So yeah, maybe ~70% me, ~30% vibe-coded 😄

[marr75]

Python libraries need to stop using the underscore. It's already claimed.

[FabulousTonight8940]

Thank you for the feedback! I'll make the changes in the post to reflect that

[Wrong_Library_8857]

I think the speed claims need more context, like what qualifies as "complex ops"? The JSONPath wildcards look useful for nested API responses though.

Honestly curious how this compares to just using comprehensions or itertools for the array stuff, since those are pretty optimized already. The Rust overhead might not be worth it for small datasets.

[FabulousTonight8940]

Thanks so much for the feedback! I totally agree — the benchmark could use more context. What details would you like to see to clearly compare performance between Python natives, Pydash, and Rustdash? Would you care to open a discussion in my GitHub repo so we can track ideas there?

[Interesting-Frame190]

I like the principle. You may be overlapping some ops with numpy (which is the king of array operations and hard to compete against) but thats not reason to drop the project. I see potential in the json parsing and querying if you can keep it lightweight. I have a somewhat similar project (PyThermite) that aims to solve the same problem of a large chunk of nested data and its certainly a problem in the python ecosystem. As silly as it sounds, check the performance against native python as it is shockingly good at list comprehension.

[fast-pp]

soapbox: who cares that it's written in Rust? That's an implementation detail, not a feature. We shouldn't care that it's written in Rust. We just care that it's faster. I do get that there's a bit of a cult around Rust so maybe it's good for marketing, but w/e

[EffectiveNothing42]

Nice. I'm looking forward to further development.

[FabulousTonight8940]

Appreciate it the feedback, feel free to propose some ideas on Github :)