gq
gq copied to clipboard
JS functions instead of Go?
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
I think that’s an interesting idea. I’ll think about it