Please compare this with `Data.Binary` in the docs

infinity0 commented 4 years ago

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 #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 kolmodin/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 commented 4 years ago

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

infinity0 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

well-typed / cborg

Please compare this with `Data.Binary` in the docs #230