hherman1 / gq Goto Github PK

just read the headline from https://changelog.com/news/Q5Yy/visit and having a first look, not knowing the details yet,

even though I am personally fluent on both Go and JavaScript, but I still think the JS version's filter map is more natural than Go's, and by supporting JavaScript's native function interfaces, you can reach a far more number of developers (JS is more than Go anway),
the type flexibility would be more useful and important in such a jq-like tool? but static typing? no need in a CLI tool

$ echo '["list", "of", "mostly", "uninterseting", null, "good/strings", "good/welp"]' | gq 'j.filter(n => n?.includes("good/"))'
  // look at a bad value `null` in the input, and JS's `?.` can handle it wonderfully
[
  "good/strings",
  "good/welp"
]

$ echo '[1, 2, 3, 4.5]' | gq 'j.map((n, i) => (n + i + 25))' 
    // what's the point using `50/2` in your example?  and JS's version you got the index naturally, useful in many cases,
[
  26,
  28,
  30,
  32.5
]

underlying I would not care in which language you implement this, and I believe you can find another JS interpreter in Go, would be better than yaegi in go,
by implementing in Go, I believe it could be faster than currently node -e ... every time if I can't figure out in jq, then I would pipe to node -p '...' or deno eval -p '...' would like to see such a tool implemented in Go and would have better performance than node or deno on command line