rust-snappy

Snappy compression implemented in Rust (including the Snappy frame format).

Data & Databases

Explore on GitHub Read Hacker News discussions

2Distinct people

3Mentions

0Explicit recommenders

516GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Snappy compression implemented in Rust (including the Snappy frame format).

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year3 dated mentions

Observed mentions: 2016-11-29 02:13:12 UTC to 2020-05-04 08:15:34 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

anewvillager·May 4, 2020

> Where are the pervasively used compression libraries in Rust? Video and audio codecs? Network stacks? Database engines? System management utilities? PKI and encryption stacks? All that stuff is still in C. After ten years of Rust success! It's not ten or 20 years, the first release of Rust was in 2015. Pre-1.0 Rust was a wildly different language, with green threads, segmented stacks, regular and wild breakage, not really a C replacement! Please understand this point. But anyway here are some projects: https://github.com/ctz/rustls a TLS library that uses https://github.com/briansmith/webpki a pki library https://github.com/burntsushi/rust-snappy a compression library https://github.com/tikv/tikv a database engine https://github.com/hyperium/tonic a gRPC library https://github.com/tock/tock an embedded OS https://lib.rs/command-line-uti

Read the rest

lities lots of CLI utilities which include system management You ask for "pervasively used" but this is not under control of Rust itself. It's not feasible to replace decades old setups in five years. The most widely deployed Rust stuff is in Firefox and some Gnome libraries AFAIK. > I mean, is it maybe fair to say that the window is closing for rust to take over a significant fraction the systems programming world? I don't see why this should be the case.

In Re: Integrating "safe" languages into OpenBSD? (2017)

burntsushi·Dec 31, 2016

Compression: https://github.com/BurntSushi/rust-snappy

In Rust is Software's Salvation

burntsushi·Nov 29, 2016

> Also, looking at the byteorder crate, I wouldn't be surprised if it's even slower than the simpler and correct loop I posted elsethread. read_num_bytes in that create uses copy_nonoverlapping, which I assume is analogous to memcpy in C. That's a very round-a-bout and inefficient way to accomplish the task, and likely patterned after similarly bad C code. It wasn't patterned after any C code. ptr::copy_nonoverlapping doesn't necessarily compile down to memcpy. Namely, concrete sizes are given, so the compiler backend can optimize this down to simple loads and stores on x86, which is probably going to do better than the bit-shifting approach. Namely, loading a little-endian encoded integer on a little-endian architecture should be as simple as a single word-sized load (because the byte swap is unnecessary). It would be interesting to cons

Read the rest

ider whether the safer and more readable bit-shifting approach could be compiled down to the same code, but when I wrote the byteorder crate, this wasn't the case. This isn't the only place that ptr::copy_nonoverlapping is useful. I used it in my snappy[1] implementation as well, specifically to avoid the overhead of memcpy. To be clear, this wasn't my idea. This is what the C++ Snappy reference implementation does as well. Avoiding memcpys in favor of unaligned loads/stores is a dramatic win. I know this because I tried to write my Snappy implementation without specific unaligned loads/stores, and it performed quite a bit worse. The performance of the Rust implementation is now on par with the C++ implementation. Of course, this is always dealing with raw bytes---there's no type punning here. ptr::copy_nonoverlapping is a bit generic for this use case. That's why we recently accepted an RFC to add read_unaligned/write_unaligned to the standard library[2]. (Which are implemented via straight-forward calls to ptr::copy_nonoverlapping.) [1] - https://github.com/BurntSushi/rust-snappy/blob/master/src/de... [2] - https://github.com/rust-lang/rfcs/blob/master/text/1725-unal...

In SeaHash: A fast, portable hash function in Rust