Fine by me. The C version was a pain in the ass to compile. The Go version compiles in less than one minute, with a simple `go build`, on Windows, Linux or any Go platform. I will take that over the faster speed every time.
This mentality is why modern software seems slower... Because it is.
So many technological advances, computers are exponentially faster in so many ways, yet we regress in performance.
It's a shame, really...
It's why you have user interfaces today that are often as slow as, or slower than the equivalent Windows 3.11 interfaces. In 1993 things took time because the processor was an actual potato and the data fetched off a floppy disk, today things are slow because the code being run is 1-10k times slower and messages need to be continuously sent to a datacenter half way around the world to inform an analytics server about your every input.
You're focusing on the developer, not the user, but this is a user tool :(
Miller has always been a user tool and will remain so.
I think the confusion arose because I did the port per se and feature-adds first (which has taken most of the time), and left analysis/optimization (even low-hanging fruit like output-buffering) until the very end -- https://github.com/johnkerl/miller/pull/786 for example merged just a couple days ago.
Another win (besides more features, and recent performance improvements) -- the Windows version is now a snap. Now `mlr.exe` takes it rightful place alongside the Linux and Mac executables (https://github.com/johnkerl/miller/releases/tag/v6.0.0-beta). Go+Windows is heavenly & I'll never need to tweak MSYS2/Appveyor/DLLs/etc again. :) See also https://miller.readthedocs.io/en/latest/miller-on-windows/