I am now working on approximating zlib's behaviors for its various compression levels (been focused just on the default level until now).
My most recent Zippy release has support for a levels parameter and includes a fast BestSpeed which is using Snappy's algorithm for finding runs that can be copied instead of the slower LZ77. Turns out the Go team did the same thing in their standard lib. The compressed output is of course fully compatible. I still need to do levels 2 - 9 + lazy matching but progress is progress. As for the standard lib vs fusion vs just GitHub+nimble discussion: 1: I'd be very happy if my zlib implementation was acceptable in part or whole for either fusion or the standard lib. I started the project as my own repo simply due to there being no friction, not as a position against the standard lib. 2: To me, zlib/gzip support is pretty standard library-ey. The deflate + zlib + gzip formats are super stable, old and extremely widespread. Once it works, it kind of shouldn't need to get touched much. It's also not something most people want to mess with. In my past lives I just wanted it to work so I could move on. I agree that dynamic, new, or opinionated projects are probably not good for the standard library, but I don't think this is troublesome there. The deflate standard is almost as old as I am lol.
