Please compare this with Data.Binary in the docs

[infinity0]

Hi, I am looking a bit more deeply into Haskell serialisation frameworks and am trying to understand the differences between this library and Data.Binary. So far I understand the following:

cborg

• pro: Tries harder to avoid security issues, such as Use fromDistinctAscList for Data.Set decoding #113
• pro: Follows an external encoding standard that is supported by multiple languages not just Haskell

Data.Binary

• pro: Is part of the standard set of haskell libraries distributed with the haskell platform
• pro: Part of the distributed-haskell / Cloud Haskell project
• con: Has 8 13-year-old design issues such as Instance for Double/Float is absolutely batty haskell/binary#69
• con: As far as I can tell, is Haskell-specific

There is also Data.Store but it readily admits to trusting the input and having known security issues (mgsloan/store#103), so I automatically discount it.

Are there any other high-level important facts that I've missed? I didn't spend too long collecting this list. From the above, it seems that Codec.Serialise is better than Data.Binary for general use, unless you have very specific requirements such as compatibility with Cloud Haskell or wanting to minimise non-haskell-platform dependencies. Would you agree?

[sjakobi]

This might be interesting to you, especially if you also care about performance: https://github.com/haskell-perf/serialization

[infinity0]

Performance is interesting, though for me (and I expect others) is of secondary importance to interoperability and security. I see your link has a comparison table for interoperability so that answers one of these things, thanks!

In terms of usage, I'll collect the hackage stats into this table here:

package	downloads last 30 days
binary	2684
cereal	1390
store	1340
serialise	491
packman	248
persist	203
flat	188

[sjakobi]

I wouldn't put too much weight on the download stats. AFAIK they're not very reliable, in part, because most packages are served by a CDN.

[infinity0]

Relatively speaking, would you say that the table is inaccurate? Even with CDNs hiding a lot of downloads, I would expect this to affect all packages equally no? And the numbers seem "big enough" that natural statistical variations wouldn't make them too inaccurate.

[sjakobi]

I don't know whether the relative frequencies have any meaning. If you want to assess usage or popularity, I'd rather go by GitHub stars or maybe reverse dependencies, e.g. https://packdeps.haskellers.com/reverse/serialise