By Artyom Kazak aka @availablegreen
Last update: January 4, 2021
I would love to have something like decorators available in Haskell — that would make parsing JSON much better. But until then I'm probably sticking with Aeson.
Right now the choice is between writing manual instances, or somehow changing the data to fit autogenerated instances, or avoiding native records entirely and using anonymous products/sums. I usually write manual instances, unless I'm doing scripting.
I am told that Nikita Volkov's jsonifier is 2–5 times faster than Aeson's
toEncoding. If you need very fast JSON encoding and you are not using
toEncoding yet, you should use
toEncoding (and declare it for all
ToJSON instances, of course). If even that is not enough, switch to 'jsonifier'.
yaml is probably the most popular choice. It uses the same representation as Aeson, and hence I don't need to write FromYAML/ToYAML instances if I already have FromJSON/ToJSON.
There's also HsYAML, which might be better (though I don't remember how), but unfortunately it's GPL-ed.
'cassava' is very commonly used, though it's old. csv-conduit might also be a good idea. I can't remember the last time I had to parse CSV; I suspect I would just pick 'cassava' if I don't need streaming and 'csv-conduit' if I do, and I don't expect problems with either.
There is also sv, which is newer and uses a "high performance streaming CSV parser based on rank-select data structures", so I thought it could be faster, but according to haskell-perf it's not faster. Too bad.
Probably tomland? Yeah, very likely 'tomland'.
I never had to parse TOML, but a) people like 'tomland' and b) there isn't anything else anyway.
Oh boy. Maybe xml-conduit?
I suspect that all XML libraries are going to be hellish. This said, at Juspay we tried 'xml-conduit' recently and it worked, so that's probably what I would go with.