I understand the apprehension. It’s completely fair to be wary of tossing out decades of battle-tested reliability, and "Rewrite It In X" syndrome is definitely a real anti-pattern in our industry. However, calling this project "dangerous and insane" ignores some very real, systemic limitations of the current rsync implementation that simply cannot be fixed without a ground-up rewrite.

Here is why creating a modern alternative is a necessary step forward, rather than just reinventing the wheel:

- Memory Safety and Security: rsync is written in C. While the maintainers do an incredible job, a memory-unsafe language will inevitably suffer from security vulnerabilities. We have seen periodic, significant CVEs related to buffer overflows and out-of-bounds memory accesses. Moving to a modern, memory-safe language structurally eliminates entire classes of these vulnerabilities.

- Architectural Bottlenecks: rsync was designed for 1990s hardware. While it uses a multi-process pipeline (generator, sender, receiver), its core file-processing loop is fundamentally serial. It was optimized for an era of low RAM and spinning disks. Today, we have NVMe drives and processors with dozens of cores. Modernizing the architecture with true multithreading and asynchronous I/O allows for massive performance gains that rsync's legacy architecture simply cannot accommodate.

- Technical Debt and Spaghetti Code: The original codebase is turning 30 years old this year (first released in 1996). Over three decades, it has accumulated a massive amount of technical debt. It is poorly documented internally, heavily patched, and relies on capturing thousands of obscure edge cases directly in the code logic rather than through clean abstractions. It has become a black box that is incredibly hostile to new contributors.

- Protocol Documentation: Because so much of the tool's behavior is implicitly defined by the code itself, the actual modern network protocol lacks comprehensive, standalone documentation. A major goal of this rewrite is to hunt down those undocumented edge cases and finally establish a clear, documented standard for the protocol.

- The Reality of Bugs: Yes, writing new code introduces new bugs. But if the fear of new bugs prevented us from writing new software, we would all still be using FTP and Telnet. Bugs are an inherent part of the development and iteration process. We write tests, we run betas, and we fix them.

The goal isn't to force everyone to switch tomorrow. It’s to build a modern, fast, and safe foundation so that when people are ready for an alternative, a robust one exists.