That’s not really how many systems work though. It’s not about “want to go slower” — it’s interoperability with systems that cannot read those new formats.  

On Dec 15, 2025, at 2:04 PM, Jason E. Aten <[email protected]> wrote:


This is pure speculation of my part, and I still use a ton of snappy, but Klaus Post's S2 and 
now the next generation MinLZ would appear to have surpassed snappy in 
performance while providing a backwards compatible migration path. 

Old data snappy compressed can be read, and new data can compressed and decompressed faster. 

So from a technical standpoint, there's not much call for snappy in new code, unless
you deliberately want to go slower than what is now possible. That is a rare want.

Links:

https://gist.github.com/klauspost/a25b66198cdbdf7b5b224f670c894ed5

https://chromium.googlesource.com/external/github.com/klauspost/compress/+/master/s2

On Sunday, December 14, 2025 at 10:43:48 AM UTC-3 Brian Olson wrote:
https://github.com/golang/snappy

2025-03-07 they made a 1.0.0 release and marked the repo as archived and read-only. I usually think of that as deprecated, but maybe in this case it's a weird way of saying they think it's perfect and will never change?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/eaf9770d-f9ed-407e-9de1-87c725d239a3n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/B605E703-C96E-46EF-B319-525A696F364A%40icloud.com.

Reply via email to