For #IPC between programs at work, I use JSON: with std{in,out} (and non-JSON messages in stderr), and additionally supporting Unix domain sockets (replacing stdin and stdout) with syslog (in place of stderr), similarly to CGI and FastCGI, supporting streaming for output (a sequence of JSON objects, until the stream is closed). Using Aeson for that, but it is a heavy and occasionally problematic dependency, and not great for manual invocation.

Back in 2016/2018 I wrote a Haskell library to derive (de)serializations of arbitrary types, using GHC.Generics, in the form similar to regular command line arguments (to be used for input) or DSVs (for output), with automated basic usage strings for --help messages, but have not switched to it: slightly worried that there may be bugs, and the help messages would be better with optparse-generic. Though there is no serialization for optparse-generic in sight, it does not cover program output, adding help messages for it requires introduction of the "Helpful" constructors.

As a side note, later I learned about Python Fire, which is a similar project in Python.

I am still using JSON (and Aeson) for that, and even need to pass JSON as a parameter in some cases (possibly just as a string, to avoid dependency on it in the IPC library), but it still feels awkward and inconvenient for manual invocation (as I do mostly for testing).

Considering how to proceed: keep it as is, update the custom library and try to use it, try to use optparse-generic with custom or manual serialization and something else for output. Or could use actual CGI/FastCGI instead of this, an HTTP server, OpenAPI?Swagger, or even SOAP (not great for manual invocation though, and complicated). Formal specifications are tempting to have, too, so that it would be more suitable for different languages. I wish there was a good option for s-expressions.

What do you use for IPC, in #Haskell or in other languages, why, and are you happy with it?