OK Grok, calm down.

It's way better than the US.

No. Apple's phones started out with only web apps. They only add the walled garden later.

It couple physically disable camera + mic + whatever, and ALSO have hooks that enable you to do extra things with it in software?

Why don't you work on improving rsync, rather than reinventing the wheel? Or create something new??

It's fine as a personal project, but as soon as you get other people using your new code, they'll be exposed to all the bugs that you are inevitably creating.

Honestly, this kind of "rewrite something battle tested in my favourite language" project is dangerous and insane.

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.

C++ destructors are implicit, while defer is explicit.

You can just look at the code in front of you to see what defer is doing. With destructors, you need to know what type you have (not always easy to tell), then find its destructor, and all the destructors of its parent classes, to work out what's going to happen.

Sure, if the situation arises frequently, it's nice to be able to design a type that "just works" in C++. But if you need to clean up reliably in just this one place, C++ destructors are a very clunky solution.

> Implicitness of destructors isn't a problem

It's absolutely a problem. Classically, you spend most of your time reading and debugging code, not writing it. When there's an issue pertaining to RAII, it is hidden away, potentially requiring looking at many subclasses etc.

Example: If a build is going on in the background, I can see when it stops.

You can use `build-tool; tput bel` to hear the bell when it ends. Some terminal allows to set the urgent flag on the windows when the bell rings.

Yeah I have used desktop notifications for such things (via notify-send etc), but I'm going to accept this explanation for transparent background as it makes some sense to me.

Windows XP was a disaster. Resistance to adopting it was industry wide, and lasted years. It was only with Service Pack 2 (which was an enormous rewrite of basically the whole system) that they started to turn the ship around.

That's insane.

I bet someone who knew Bash well enough could probably just optimise the original script (xargs -P perhaps, to parallelise the calls to ln?), but no it must be rewritten in Rust, because reasons.