How close can pure functional programming get to C?
- ID
- 39130
- Status
- summarized
- Published
- 24 Oct 2026, 11:43 AM
- Fetched
- 25 Oct 2026, 1:37 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://rtfeldman.com/fp-vs-c
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 25 Oct 2026, 1:37 AM
- Tags
- Audience
- developersvibe_coders
What happened
Richard Feldman benchmarked roc-deflate — a DEFLATE compression package written by Niclas Ahden in Roc, a functional language still weeks away from its 0.1.0 release — against C's libdeflate across 144 benchmarks on the Silesia corpus. Roc came out a median 8.9% slower on an AMD Ryzen 9 3900X and 2.6% slower on a 2021 M1 MacBook Pro, with identical outputs, and only on non-streaming APIs since roc-deflate has no streaming support yet. The piece is framed against Lean 4's lean-zip, which beat Rust's miniz_oxide (15% faster at its fastest setting, 8.8% smaller output) but still lost badly to libdeflate.
Why it matters
The concrete decision this informs: if you were planning to drop into C or Rust for a scalar, non-SIMD hot path, a single-digit-percent median gap (2.6% on M1) no longer justifies a rewrite — but libdeflate's edge comes from architecture-specific SIMD that the author says can't be expressed in Lean, so vectorization-heavy workloads still belong in C. Note the caveats before quoting the number: non-streaming APIs only, one optimizer, a pre-0.1.0 language, and a benchmark run on the author's own machines.
Discussion angle
Where does the remaining ~9% actually live — compiler codegen, allocation strategy, or the SIMD intrinsics the author says the language can't reach? And does a pre-0.1.0 language getting within 2.6% on M1 change how you'd scope a performance-sensitive side project?