A jq clone focussed on correctness, speed, and simplicity
3.7k
Stars
115
Forks
27
Open issues
30
Contributors
AI Analysis
jaq is a Rust implementation of the jq JSON query language, designed as a drop-in replacement with emphasis on correctness, startup performance, and code simplicity. It serves developers and DevOps engineers who need fast JSON processing at the command line or embedded in Rust applications, with additional format support (YAML, CBOR, TOML, XML) beyond standard jq. It is not a general-purpose programming language and is best suited for those already familiar with jq's domain-specific query syn...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Rust jq clone balancing correctness, speed, and library usability with modest but stable adoption
jaq is a Rust implementation of jq focused on three design principles: correctness (more predictable behavior than jq), performance (lower startup time, faster on many workloads), and simplicity (smaller codebase, Rust safety guarantees). It works as both a CLI tool and a reusable library (jaq-core). It adds support for YAML, CBOR, TOML, and XML beyond standard JSON. Adoption appears concentrated among users processing many small files or embedding JSON processing in Rust applications, rather than broad replacement of jq in existing pipelines.
Created December 2020 by 01mf02, jaq emerged partly from frustration with jq 1.6's 50ms startup time. Although jq 1.7 improved this, jaq continued evolving with its own feature set and library design. The project has maintained steady activity over ~5.5 years, positioning itself as a correctness-focused alternative rather than a direct competitor.
Stars grew from 0 to 3,666 over 5.5 years at a modest but consistent pace (~7 stars in the last week). Growth appears driven by: (1) Rust ecosystem adoption, (2) availability on Homebrew and package managers (Repology shows broad packaging), (3) library appeal for embedded JSON processing in Rust, and (4) niche interest from users hitting jq's limitations. Not trending explosively, but showing neither decline nor stagnation.
Adoption not verified in concrete terms. Indicators suggesting real use: (1) Available on Homebrew and across major package managers (repology badge); (2) jaq-core published to Crates.io with documentation; (3) playground provided (gedenkt.at/jaq/), suggesting user base; (4) comparatively high star count (3,666) for a niche tool. However, no case studies, company endorsements, download metrics, or public user testimonials cited in README.
Based on README, jaq is implemented in Rust with a two-layer design: CLI binary and jaq-core library. The library supports arbitrary data types via a generic ValT trait, enabling safe multithreading and non-JSON inputs. README emphasizes 'simple and small implementation' to reduce bugs. Appears to use a compiled approach (mentions 'compile and run jq programs') rather than interpretation. Actual code structure not inspectable from README alone.
Not documented in README. Build status badge shown (CI passing), but no explicit test coverage metrics, test strategy, or test count disclosed.
Last push 2026-06-29 (4 days before evaluation date). CI badge present and passing. Crates.io and docs.rs entries maintained. No evidence of abandonment; activity is low-frequency but regular. README and documentation appear current (mentions jaq 3.0 in benchmarks). Slow update cadence is consistent with mature, stable projects rather than active development.
ADOPT IF: you embed JSON/YAML/CBOR/TOML/XML processing in Rust applications and want Rust library safety and multithreading support; you process many small files and startup time matters; you need jq compatibility with stricter correctness semantics. AVOID IF: your team standardizes on jq in shell pipelines and you need maximal community documentation and third-party integrations; you require support for jq's latest experimental features; you need a single canonical implementation (jq remains the reference). MONITOR IF: you maintain jq-dependent infrastructure and are evaluating performance alternatives; you're building a new data processing pipeline in Rust and want to weigh jaq-core library benefits against the jq ecosystem's maturity.
Independent dimensions
Mainstream potential
3/10
Technical importance
6/10
Adoption evidence
4/10
- Adoption not verified in large-scale production systems; most evidence is indirect (package availability, star count). Real-world breakage or missing features could surface post-adoption.
- Single-maintainer project (01mf02). Bus factor risk if primary contributor becomes unavailable; project has survived 5.5 years but growth remains slow, possibly limiting appeal to contributors.
- Correctness vs. compatibility tradeoff: README states jaq 'aims to provide more correct implementation while preserving compatibility in most cases,' implying edge-case divergence from jq. Undocumented compatibility gaps could break scripts.
- Library interface (jaq-core) may be unstable; Crates.io versioning not inspectable from README. Early major versions or rapid API churn could frustrate Rust library users.
- Performance benchmarks in README are self-reported on one machine (AMD Ryzen 5 5500U). No independent validation; performance advantage may not generalize across workloads, hardware, or input sizes.
jaq likely remains a specialized tool for Rust ecosystem users and performance-sensitive niche workflows, growing slowly and steadily rather than mainstream. Probability of displacing jq in general use is low, but probability of becoming the de facto jq library for Rust applications is moderate if jaq-core API stabilizes and adoption grows incrementally.
Explore similar
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Rust
- License
- MIT
- Last updated
- 4d ago
- Created
- 68mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Dependency structure pulls in transitive dependencies with all default features
-help | : Broken Pipe should not be shown
`del(f)` changes the order of keys
jaq-all pulls in all jaq-fmts formats
flowers.jq compatibility 🌻
Top contributors
Similar repos
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
3.7k | +4 | Rust | 8/10 | 4d ago |
|
|
6.1k | — | Rust | 7/10 | 3mo ago |
|
|
35.1k | — | C | 8/10 | 1w ago |
|
|
3.8k | — | Go | 8/10 | 3d ago |
|
|
3k | — | Python | 7/10 | 7d ago |
|
|
15.7k | — | Go | 8/10 | 1d ago |
Category leader. jaq is compatible with jq but emphasizes correctness and startup speed. jq 1.7+ narrowed the performance gap; jaq remains faster on many benchmarks but serves niche use cases (library embeddability, correctness edge cases, non-JSON formats) rather than replacing jq for existing workflows.
Similar positioning: jq clone in a different language. gojq focuses on portability and ease of installation. jaq emphasizes Rust library ergonomics and safety; gojq may appeal more to Go ecosystems. Performance comparable on many benchmarks; jaq wins on some (group-by, kv-update), gojq on startup (empty).
Broader scope: YAML/XML/JSON processing. yq higher star count and adoption. jaq and yq address overlapping use cases (multi-format support) but jaq emphasizes jq compatibility and Rust library design; yq is more general-purpose tool for config file manipulation.
Interactive JSON viewer/browser. Different problem domain (exploration vs. transformation). Both Rust-based, but jnv is not a jq clone and serves a distinct workflow (visual inspection rather than scripted transformation).
Interactive JSON pager/viewer with jq filtering. Similar audience (JSON workflow optimization) but different primary use case. jless higher stars; both Rust; jaq is transformation-focused, jless is navigation-focused.