Well, blog entry is still there at https://orbisappsec.com/blog/critical-buffer-overflow-in-ojs... but it is total nonsense and a hallucination.

I was contacted by the submitter and they apologized and removed the blog entry. It was AI generated. It was nice to see they were upstanding enough to correct it. That's a plus in my book.

it is good to hear that they at least admitted to it and complied.

Another alternative is oj, https://github.com/ohler55/ojg. I don't know how the performance compares to jq or any others but it does use JSONPath as the query language. It has a few other options for making nicely formatted JSON and colorizing JSON.

I've been writing Lisp code off and one since the 80s. The standard for Common Lisp has to be sbcl but the REPL is pretty minimal. The available packages tend to be more limited than Go which I've been using a lot lately. I did find a way to have a more functional REPL and also have access to all the Go packages by writing SLIP (https://github.com/ohler55/slip). Yes I know this is a plug for SLIP and if that offends anyone I apologize. The reasons mentioned for developing it are valid though and I've managed to use Lisp for almost all the data mining and processing tasks.

Over the last 2 or 3 years I've been building a Common LISP implementation in Go so that Go packages can be utilized by LISP code. Building a REPL with lots of interactive features was rewarding as was taking up the challenges of the object systems (CLOS and Flavors) and generics. Just open sourced it at the start of January. https://github.com/ohler55/slip

Thanks for the help.

After several years of development here is a mostly Common LISP implementation written in Go with a REPL, CLOS, generics, Flavors, and much more.

If you prefer JSONPath as a query language, oj from https://github.com/ohler55/ojg provides that functionality. It can also be installed with brew. (disclaimer, I'm the author of OjG)

JSONPath is also supported by Postgres!

Helpful when querying JSON API responses that are parsed and persisted for normal, relational uses. Sometimes you want to query data that you weren’t initially parsing or that matches a fix to reprocess.

speaking of classic databases: can anyone explain to me, a dummy, why any syntax like this or even GraphQL is preferable to "select a.name, a.age from friends a where a.city = 'New York' order by a.age asc"?

I'm clearly biased but oj which uses JSONPath is my preferred JSON manipulator. It can be installed with brew. It may not be for everyone but some of you might like it.

My experience is quite a bit different. Of course the examples I would use are more like what you might expect in real code. The comparison should be against code that calls a function that either returns and error and checks that error or one that panics and recovers. The overhead of returning the extra error and then the conditional used to check that error is more than a panic on error and recovery somewhere up the stack. This was not true in the early days of go but it is true today.

It really depends on the code being written. Try one approach then the other and see if it works better in your situation. For the example in the article there is really no need for an error check in the idiomatic case so why compare that to using panic. If there was an error to check the result would be much different.