Once you’ve learned it, Rust is just a very nice compiled language to work with.

You get higher level constructs than in C++, a language without a billion weird edge cases, a modern package manager, and much more. In my experience, my code written in Rust is more likely to work as intended, both because of the stricter compile-time checks, but also because language features like sum types make it easier to check the core logic at compile time.

I work in both C++ and Rust, among other languages, but these days I never reach for C++ for a new project

Those people are wrong. The 3.4.3 release passes all the integration tests in the 3.4.1 release’s test-suite, which is the last release without LLM code. You can easily test this yourself

That’s definitely a possibility, along with the possibility that countries with worse English language skills might be underrepresented on GitHub, despite having universal healthcare. Conversely, if the US is over-represented on GitHub, then the pool of US developers who are not already active on GitHub may also be depleted compared to other countries. However, that is not something we can read out of the available evidence.

The most we can conclude is probably that the US getting universal healthcare might result in an increase in available OSS developers, depending on which assumptions turn out to be correct, but suggesting that it would lead to an order of magnitude increase is surely premature

Universal Healthcare would increase the pool of willing developers by an order of magnitude here.

I’m not so sure. The problem is not a lack of developers. The problem is a lack of developers interested in working on rsync, or on any other specific project you can name. Most developers would rather work on their own projects.

I would also question whether or not universal healthcare (though unquestionably a good thing) would actually result in such an increase in available developers. The following study looked at the geographical distribution of OSS developers in 2021, via Github contributions, and found that the US had a similar number of OSS developers per capita compared to similar countries that do have universal healthcare (see table 2):

https://www.sciencedirect.com/science/article/pii/S0040162522000105

Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.

Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:

• rsync: 99.0%
• restic: 93.2%
• rclone: 87.5%
• union: 82.9%
• syncthing: 74.4%

As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.

Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync

Yes, there’s been several regressions that would’ve been caught by the original tests, but missed by the new vibe-coded tests.

That is directly contradicted by what the developer of rsync wrote in the linked article:

yes, there were regressions in some use cases of rsync in the 3.4.3 release. … None of those cases were covered by the existing rsync test suite or by all the manual testing I did (yes, I use rsync, I don’t just develop it).

It’s possible that somebody in the issue you linked to pointed to a test that would have caught one of the regressions, but I was not able to find it in the 327 comment mess. A direct link would be appreciated, if that is the case.

But I doubt that you will find such a comment. Because I tried running the 3.4.1 test-suite with the 3.4.3 binary, and all tests passed

I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:

They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.

The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.

Most basic functions are imported from a shared module (rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amount

But GCC did not improve their error messages (much) prior to Rust, despite Clang’s error messages comparing favorably to GCC even before Rust 1.0 was released, as for example discussed in

https://gcc.gnu.org/wiki/ClangDiagnosticsComparison?action=recall&rev=1

Rust itself is 14 years old, slightly older than above wiki page, and even back then it had great error messages, though they’ve also improved since. Here’s a fun site where you can see how error messages have evolved through Rust’s life:

https://kobzol.github.io/rust/rustc/2025/05/16/evolution-of-rustc-errors.html

It’s only very recently that GCC has started to catch up, for example with some nice improvements in GCC 15:

https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15

Do yourself a favor and get a USB stick with Linux on it, regardless of whether or not you are going to use it to install Linux.

When stuff breaks, you’ll regret not having a bootable media like that. Also, if you are using windows and Bitlocker (the default these days), then be sure to store your encryption keys somewhere, where you can easily access them. Otherwise you won’t be able to access your Windows drives

“Free” and “libre”. But this has only ever referred to the software itself, not to the hardware needed to use it.

That should be obvious, since otherwise almost no OSS would be FLOSS. After all, you have to buy a PC or another device to run it

At this point the people complaining about Rust at every opportunity have become more annoying than the “rewrite it in Rust” people ever were