The only (arguably*) baseless claim in that quote is this part:

You do understand you're making that claim on the post discussing the proposal of Safe C++ ?

And to underline the absurdity of your claim, would you argue that it's impossible to write a"hello, world" program in C++ that's not memory-safe? From that point onward, what would it take to make it violate any memory constraints? Are those things avoidable? Think about it for a second before saying nonsense about impossibilities.

That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive.

Care to take a shot at figuring out why COBOL is still used today?

I mean, feel free to waste your time arguing for rewrites in your flavor of the month. That's how many failed projects start, too, so you can have your shot at proving them wrong.

But in the meantime you can try to think about the problem, because "rewrite it in Rust" is only reasonable for the types who are completely oblivious to the realities of professional software development.

think the lack of UI

Even git ships with git-ui. It's not great, but just goes to show how well informed and valid your criticism is.

https://git-scm.com/docs/git-gui/

Nonetheless

You didn't provided a single concrete example of something you actually feel could be improved.

The most concrete complain you could come up was struggling with remembering commands, again without providing any concrete example or specific.

Why is it so hard for critics to actually point out a specific example of something they feel could be improved? It's always "I've heard someone say that x".

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

TIL rust has some sort of ratings for libraries/dependency code.

A random guy going through the trouble of putting together a site to subjectively rate other people's work is hardly something that's language-specific.

I'd wager that adding a single tag/field to represent the programming language is all it takes to make the system universal.

Also, that's not even language-specific. It's package-centric.

I get it, joining bandwagons is fun. That's not a substitute for thinking things through, though.

By the way, npm even supports package auditing, warnings, and autopromoting packages and its dependencies. You don't hear people constantly parroting switching projects to Node.js over this, though.

It seems to be a combination of both things. They believe that switching will attract contributors and make it more modern… but also they seem to have had some trouble with thread safety in C++ that would have required them to do some restructuring anyway.

It still feels like at best they are optimizing for the wrong metric and at worse they are just trying to rationalize an arbitrary choice.

I mean, the first reason they point out is "high probability of still being relevant in a decade." I mean, is Rust even a candidate in this domain? All leading programming languages have been around for longer than Rust and are actually specified in international standards, which ensures they will be around for essentially all eternity. Rust provides nothing of the sort. Is there anyone willing to put their hands in the fire for the expectation they will be able to build today's Rust projects a decade from now?

Also, Rust is renowned for having a steep and tough learning curve. Those are hardly the traits you seek to increase your potential userbase.

More importantly, threading stuff is limited to key architecture components that once in place are expected to change little to nothing. It's like picking .NET because you think it supports background processes well. Except the bulk of your code changes won't touch that, so what's the point?

Anyway, anyone is free to invest their time and effort in any venture without having to explain their motivations to anyone.

99% of all servers a unix, which means code written for servers

This is where you start to get things the wrong way.

The code that runs on a server isn't necessarily built from source code in the same platform. You can easily have entire teams working on Windows on projects that incidentally only run on Unix-like OSes after they are deployed, which is the case of the whole ASP.NET stack.

It makes no sense to dictate what newline character you enforce a project based not on which platform a team will use to work on the source code but on whatever platform the project may or may not be deployed.

This approach is particularly absurd once you take into account the fact that Git supports line ending normalization, and it supports configuring which newline is used when checking out source code not only in a per-repository basis but also on a per-user and even per-local repository basis.

Maybe it’s time for windows to stop using CRLF and join the modern world?

Why do you think there is a problem and that's a solution?

Non profit doesn’t mean they earn nothing

You need a valid business model to keep an organization ticking. Staff doesn't live out of hopes and dreams. It's hard enough to get a for-profit software company to stay up. If your starting point is that the company is not focused on getting a profit then it all sounds as hopes and dreams instead of an actual business plan.

Use unsafe and write like you’re a C/C++ programmer. You can do it.

Onboard the C/C++ project to any C++ static code analysis tool and check back with me later.

This is a nothingburger.

I’m sorry, which of those recent commits aren’t things a single linter run would catch?

Ask yourself why the code still had those typos, and why nobody did anything about it except the guy contributing code cleanup commits.