APT Rust requirement raises questions

📝 Discussion Summary (Click to expand)

The discussion revolves around three primary, interconnected themes:

1. The Difficulty and Implications of Rust-to-C Transpilation

There is significant debate over whether translating Rust code (or its LLVM IR) into C code is feasible or desirable, focusing on the semantic differences between the two languages, particularly around Undefined Behavior (UB).

Supporting Quote: Regarding the semantic mismatch, user "adwn" noted, "For one, signed integer overflow is allowed and well-defined in Rust (the result simply wraps around in release builds), while it's Undefined Behavior in C. This means that the LLVM IR emitted by the Rust compiler for signed integer arithmetic can't be directly translated into the analogous C code, because that would change the semantics of the program."

2. Skepticism Regarding "Rewrite Everything in Rust" Evangelism

Many participants expressed frustration with what they perceive as excessive zeal in promoting Rust, arguing that simply rewriting existing, "battle-tested" C/C++ software (like apt or sudo) is often a waste of effort, introduces new risks, or ignores the benefits of existing solutions.

Supporting Quote: User "epolanski" stated, "The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality."
Supporting Quote (Rebuttal to "Battle-Tested"): User "marcosdumay" countered this perspective by highlighting the ongoing need for maintenance: "Cue for all those battle tested programs that people keep finding vulnerabilities several decades after they got considered 'done'."

3. The Complexity and Density of Rust Syntax

A notable side discussion focused on the perceived complexity and "unreadability" of Rust, particularly when advanced features like lifetimes are involved, leading to a debate on whether this aesthetic choice aids or hinders adoption and maintenance.

Supporting Quote: User "dv35z" questioned this by asking, "Is there a 'Kotlin for Rust'? or another high quality system language we ought to be investing in? I genuinely believe that languages ought to start with 'newbie friendliness', and would love to hear challenges to that idea."
Supporting Quote (Defending Density): User "SAI_Peregrinus" argued that the perceived density is necessary to express the necessary semantics: "I think the main issue people who don't like the syntax have with it is that it's dense. We can imagine a much less dense syntax that preserves the same semantics, but IMO it'd be far worse."

🚀 Project Ideas

Rust-to-C Semantic Diff Generator (Rust2C-Diff)

Summary

A tool that accepts Rust code and attempts to translate it into C code, but specifically highlights and catalogs all semantic deviations (e.g., wrapping integer overflow, panic handling) that occur because Rust semantics cannot be unambiguously mapped to standard C.
The core value proposition is providing developers an explicit, verifiable "cost report" for any hypothetical Rust-to-C transpile, moving the "swimming upstream" debate into concrete, actionable data rather than abstract accusations.

Details

Key	Value
Target Audience	Language designers, advanced Rust developers exploring targeting non-LLVM C codebases, and static analysis tool builders.
Core Feature	Rust code input -> LLVM IR -> (Attempted) C output + Semantic Drift Report detailing differences (e.g., Rust `i32` overflow wrapping vs. C UB).
Tech Stack	Rust (for parsing/IR handling), C front-end for LLVM (as a starting point), custom visitor logic to detect known semantic gaps (like `checked_add` equivalents).
Difficulty	High
Monetization	Hobby

Notes

This directly addresses the back-and-forth regarding the difficulty of translating Rust's defined behavior (like wrapping overflow) into C's Undefined Behavior, as pointed out by adwn and simonask.
It moves beyond proving impossibility and instead quantifies the difficulty, which HN users appreciate as concrete evidence.

Dependency-Aware Toolchain Portability Service (DATPS)

Summary

A cloud service that analyzes large software repositories (like APT or Coreutils) being ported to a new language (like Rust) and automatically maps or mocks existing C/C++ dependencies required only by legacy build systems or niche ports.
It solves the problem of dependency chain blockage and the difficulty of supporting obscure architectures when moving to a language like Rust, which often relies on LLVM.
The core value proposition is decoupling required language features from building out a full, production-grade, native toolchain port for every niche system.

Details

Key	Value
Target Audience	Distribution maintainers (like Debian), large open-source project maintainers transitioning core utilities.
Core Feature	Dependency mapping, pattern-matching build artifact emulation (e.g., generating mock headers or minimal C stubs for unsupported libraries), and architecture/toolchain metadata indexing.
Tech Stack	Python/Go (for orchestration), database for dependency metadata, containerization (Docker/Podman) for sandboxed build environments.
Difficulty	Medium
Monetization	Hobby

Notes

Addresses the pain point raised by kevin_thibedeau and razighter777 concerning the extra burden of porting the toolchain (like Rust) rather than just the application source code when supporting many niche architectures.
If a toolchain like rustc_codegen_gcc isn't ready for sh4, this service provides a temporary, targeted workaround for source code compilation.

Battle-Tested Utility Rewriting Verification Suite (BTU-VFS)

Summary

A standardized testing harness/framework designed specifically for validating Rust rewrites of established, security-critical C/C++ tools (like sudo, apt, or Unix utilities).
It incorporates historical bug data (CVEs, known edge cases) from the original C/C++ codebase into the new Rust project's regression suite, focusing on failing the rewrite if it doesn't handle the documented historical failures.
The core value proposition is providing the necessary verification confidence (Cthulhu_, az09mugen) to overcome skepticism when replacing "battle-tested" software with a new implementation.

Details

Key	Value
Target Audience	Developers performing critical utility rewrites (e.g., Coreutils in Rust, next-gen package managers).
Core Feature	Ingestion of historical bug tracking data (e.g., `sudo` CVEs) mapped to specific functional tests; automatic generation of integration tests targeting known memory-unsafe code paths in the original C code.
Tech Stack	Python/Rust integration, configuration-as-code (YAML/TOML) for test case inclusion, integration with fuzzing tools.
Difficulty	Medium
Monetization	Hobby

Notes

Directly tackles the arguments made by az09mugen and epolanski regarding trusting rewrites over code that has "decades of battle testing."
By focusing verification efforts on known failure modes of the old code, it builds trust that the rewrite is not just memory-safe, but functionally superior or at least equivalent.