Jetro – JSON query engine for Rust (jq-like DSL with compilation and VM)

Jetro는 Rust로 구현된 고성능 JSON 쿼리 엔진으로, jq와 유사한 DSL을 제공하며 컴파일과 VM 기반 실행을 지원합니다. 바이트 단위 API를 제공해 simd-json과 연동하며, 필터링, 정렬, 집계, 패치, 패턴 매칭 등 복합적인 JSON 쿼리와 변형을 하나의 표현식으로 처리할 수 있습니다. 지연 평가와 최적화된 실행 경로를 통해 효율적인 쿼리 수행이 가능하며, serde_json::Value 타입으로 결과를 반환합니다. Rust 환경에서 JSON 데이터 처리 및 변환을 간결하고 빠르게 구현하려는 AI/ML 데이터 파이프라인이나 서비스 개발자에게 유용합니다.

https://github.com/mitghi/jetro

#rust #json #queryengine #dsl #serde_json

GitHub - mitghi/jetro: High-performance JSON query engine for Rust (jq-like DSL with compilation & VM)

High-performance JSON query engine for Rust (jq-like DSL with compilation & VM) - mitghi/jetro

GitHub
For the first time I'm seriously dealing with #rust Errors.
The situation is that my son and I built a little library that has to deal with several other libraries:
#serde_json
#lapin
#deadpool
and all these libraries introduce their own Errors.
Our lib is made to allow for data processing that also introduces its own errors.
And now, once the data processing is engaged, the results of it have to be communicated to the outer world. Lots of different Errors might have happened in the rather complicated processing path the whole processing chain travels along.
This was the reason I initially opted out for a simple and unique Error type, that is String.
Then came the translation issues, because the outer world might want to interpret the errors in its own language, so the String Error type is not an option any more.
All things said, I'm grateful for #rust's match. The whole complication introduced by dealing with all sorts of Errors actually helps me in understanding how our lib works.
And our little library will end up as a not so little library, as it seems.