Comment by rozzie
16 hours ago
Some background on one of the other two golang implementations mentioned in the comments.
Years ago I hired an Upwork contractor to port v1.5.3 to golang as best he could. He did a great job and it served us well, however it was far, far from perfect and it couldn't pass most of the JS test suite. The worst was that it had several recursion bugs that could segfault with bad expressions.
That was the now-deprecated implementation at
https://github.com/blues/jsonata-go
Early in 2025 I used Claude Code and Codex to do a proper, compliant port that passes the full set of tests and is safe. It was most certainly not a trivial task for AI, as many nuances of JSONata syntax derive from its JS roots.
Regardless, it was a great experience and here's the 2.0.6 AI port, along with a golang exerciser that lets you flip back and forth between the implementations. We did a seamless migration and it's been running beautifully in prod in Blues' Notehub for quite a while - as a core transformation capability used by customers in our JSON message pipeline.
I was also involved in writing a clean-slate port of JSONata after finding issues in the jsonata-go repo and not wanting to run the javascript version in a sandbox. It was relatively easy until we stressed it with 20 layers of nested context and 5000 line expressions and suddenly we had memory explosions not present in the JS version.
JSONata is too tied to the language. Looking back, we should have slightly altered the spec and written some code mods. we didn't have customers bringing their existing JSONata over so they wouldn't notice the differences.
Why not issue a pull request to the JSONata Github project mentioning your implementation in the docs/READMEs? That goes for OP's port too of course.