Rust inadequate for text compression codecs?

Rust vs C/C++ for codecs

• Several commenters with codec/image decompressor experience felt Rust brings little benefit in the tight inner loops; C or C++ often ends up simpler for “gritty fast algorithmic code.”
• Others argue Rust can match C/C++ performance for codecs if you use idiomatic patterns (iterators, careful unsafe) and that it shines for the API surface and caller safety.
• Niche, performance‑critical codecs might be better served by specialized languages like Wuffs, or by hand‑written assembly irrespective of host language.

Assembly, compilers, and language tooling

• Rust’s inline assembly is seen as more ergonomic and consistent than C/C++’s, largely because Rust defines it in the language and mostly has one compiler.
• Debate over whether multiple front‑ends (e.g., gccrs) are a benefit (portability, ecosystem diversity) or a liability (dialects, user‑hostility).
• Some fear Rust adopting C++‑style fragmentation if multiple front‑ends diverge; others note that a precise spec, not ISO standardization, is what really prevents dialects.

Dispatch, bounds checks, and performance

• One commenter claims the article mischaracterizes C++’s static vs dynamic dispatch; CRTP plus virtuals can mix them, but others argue this is fragile and overly clever.
• The measured ~13% slowdown from bounds‑checked access (.at() vs []) makes some readers wary of using checked indexing in hot paths.
• Others say across an application the cost is usually single‑digit percent and worth it for safety, except in very tight parsers/codec loops.
• Rust is said to be good at eliding bounds checks when using iterators; pointer‑style code can defeat these optimizations.

Panics, unwrap/expect, and error handling

• Many push back on the article’s framing that panics “hide” in unwrap/expect; in Rust these functions are explicitly defined to panic and are treated as assertions.
• Strong disagreement over whether libraries should “never abort”:
  • One camp: libraries must never terminate the process; all failures, including invariant violations, should be exposed as recoverable errors.
  • Opposing camp: for broken internal invariants, aborting/panicking is appropriate; trying to continue with corrupted state risks worse bugs and vulnerabilities.
• Long subthread compares C libraries (often UB or rare “INTERNAL” error codes) with Rust’s preference for panics, framing it as trading RCE‑class issues for DoS.

“No‑panic Rust” and library design

• A linked “no‑panic Rust” approach proposes never panicking in libraries, turning all failures into Result and avoiding process termination.
• Critics question scalability, ergonomics, and user experience: APIs would become cluttered with error channels for situations that “should never happen,” and real code examples are requested.
• General consensus: panics are appropriate for impossible states/bugs; for normal, expected errors libraries should use Result.

Meta‑assessments of the article

• Several readers think the author is relatively inexperienced with Rust idioms (e.g., treatment of unwrap, bounds‑check elision, low‑level patterns).
• Others nonetheless find the exploration of static vs dynamic protections and the assembly‑level tuning of codecs interesting and in the tradition of classic systems‑programming articles.