Zlib-rs is faster than C

1. zlib-ng

   1 19 1,747 9.1 C

   zlib replacement with optimizations for "next generation" systems.

   

   I'm not sure why people say this about certain languages (it is sometimes said about Haskell, as well).

   The code has a C style to it, but that doesn't mean it wasn't actually written in Rust -- Rust deliberately has features to support writing this kind of code, in concert with safer, stricter code. This isn't bad, it's good. Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." https://github.com/zlib-ng/zlib-ng/blob/50e9ca06e29867a9014e...

2. CodeRabbit

   coderabbit.ai featured

   CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

   

3. rust

   2 2,810 102,696 10.0 Rust

   Empowering everyone to build reliable and efficient software.

   

   Why can’t something be faster than C? If a language is able to convey more information to a backend like LLVM, the backend could use that to produce more optimised code than what it could do for C.

   For example, if the language is able to say, for any two pointers, the two pointers will not overlap - that would enable the backend to optimise further. In C this requires an explicit restrict keyword. In Rust, it’s the default.

   By the way this isn’t theoretical. Image decoders written in Rust are faster than ones written in C, probably because the backend is able to autovectorise better. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...).

   grep (C) is about 5-10x slower than ripgrep (Rust). That’s why ripgrep is used to execute all searches in VS Code and not grep.

   Or a different tack. If you wrote a program that needed to sort data, the Rust version would probably be faster thanks to the standard library sort being the fastest, across languages (https://github.com/rust-lang/rust/pull/124032). Again, faster than C.

   Happy to give more examples if you’re interested.

   There’s nothing special about C that entitles it to the crown of “nothing faster”. This would have made sense in 2005, not 2025.

4. zlib-rs

   3 1 445 9.6 Rust

   A safer zlib

   

   It's... basically written in C. I'm no expert on zlib/deflate or related algorithms, but digging around https://github.com/trifectatechfoundation/zlib-rs/ almost every block with meaningful logic is marked unsafe. There's raw allocation management, raw slicing of arrays, etc... I don't know that this is a direct transcription of the C code, but if you were to try something like that this is sort of what it would look like.

   I think there's lots of value in wrapping a raw/unsafe implementation with a rust API, but that's not quite what most people think of when writing code "in rust".

5. cve-rs

   4 6 4,355 6.4 Rust

   Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀

   

   > Even validators have bugs

   Yep! For example, https://github.com/Speykious/cve-rs is an example of a bug in the Rust compiler, which allows something that it shouldn't. It's on its way to being fixed.

   > or miss things no?

   This is the trickier part! Yes, even proofs have axioms, that is, things that are accepted without proof, that the rest of the proof is built on top of. If an axiom is incorrect, so is the proof, even though we've proven it.

6. unsafe-code-guidelines

   5 75 683 3.5

   Forum for discussion about what unsafe code can and can't do

   

   This is definitely true right now, but I don't think it will always be the case.

   Unsafe Rust is currently extremely underspecified and underdocumented, but it's designed to be far more specifiable than C. For example: aliasing rules. When and how you're allowed to alias references in unsafe code is not at all documented and under much active discussion; whereas in C pointer aliasing rules are well defined but also completely insane (casting pointers to a different type in order to reinterpret the bytes of an object is often UB even in completely innocuous cases).

   Once Rust's memory model is fully specified and written down, unsafe Rust is trying to go for something much simpler, more teachable, and with less footguns than C.

   Huge props to Ralf Jung and the opsem team who are working on answering these questions & creating a formal specification: https://github.com/rust-lang/unsafe-code-guidelines/issues

7. portable-simd

   6 20 959 7.8 Rust

   The testing ground for the future of portable SIMD in Rust

   

   Others have already addressed the "unsafe" smell.

   I think the bigger point here is that doing SIMD in Rust is still painful.

   There are efforts like portable-simd [1] to make this better, but in practice, many people are dropping down to low-level SIMD intrinsics and/or inline assembly, which are no better than their C equivalents.

   [1]: https://github.com/rust-lang/portable-simd

8. embassy

   7 85 6,586 9.9 Rust

   Modern embedded framework, using Rust and async.

   

9. InfluxDB

   influxdata.com featured

   InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.

   

10. totally-safe-transmute

    8 18 256 0.0 Rust

    

Suggest a related project