Speaking as an annoying Rust user, you’re being bigoted. I’m annoying, but the vast majority of Rust users are normal people who you wouldn’t even know are using Rust.

Don’t lump all the others in with me, they don’t deserve that.

Which is exactly the position that the Rust for Linux devs have understood and accepted for themselves, and yet they still get yelled at (literally, in public, on recordings) by C Linux devs for existing.

Oh and they get snidely told that introducing the Rust language must be a mistake because suggestions to introduce other languages to the kernel turned out to be mistakes and obviously Rust is the same as all those other languages according to C developers who, by their own admission, have never used or learned anything about Rust beyond a superficial glance at some of its syntax (again this was recorded from a public event).

Rust makes sense though.

Yeah the only way it would be that high is if it lumps C and C++ together. But at that point it may be an underestimate.

A better language wouldn’t have any need to use POSIX signals in this way.

I really don’t think that there is any perfect programming language.

You’d be wrong 🦀🦀🦀🦀🦀

Still much better than C++ templates, and I say that as someone who used to genuinely love C++ template metaprogramming. Admittedly Rust traits+generics are far more limited than C++ templates, but very often I find that to be a positive. The list of things that I feel traits+generics are missing is small and rapidly shrinking.

A good enough compiler would prevent them from happening 🦀

Sorry to be pedantic but Rust only guarantees no data races can happen. It does not prevent race conditions more generally.

Don’t get me wrong, I absolutely love the language for sparing me from the hell that is data races, but the language alone won’t solve race conditions for you.

🦀🦀🦀🦀🦀🦀🦀🦀

I use thread sanitizer and address sanitizer in my CI, and they have certainly helped in some cases, but they don’t catch everything. In fact it’s the cases that they miss which are by far the most subtle instances of undefined behavior of all.

They also slow down execution so severely that I can’t use them when trying to recreate issues that occur in production.

I’m not sure if you’re genuinely asking what a test suite is or if this is a sarcistic joke about how no one bothers to test their C++ code.

And even if you do get to use pure modern C++ you’ll still get burned by subtle cases of undefined behavior (e.g. you probably haven’t memorized every iterator invalidation rule for every container type) that force you to spend weeks debugging an inexplicable crash that happened in production but can only be recreated in 1/10000 runs of your test suite, but vanishes entirely if you compile in debug mode and try to use gdb.

And don’t even get me started on multi-threading and concurrency.

There’s a difference between “You have to decide when to synchronize your state” and “If you make any very small mistake that appears to be perfectly fine in the absence of extremely rigorous scrutiny then this code block will cause a crash or some other incomprehensible undefined behavior 1/10000 times that it gets run, leaving you with no indication of what went wrong or where the problem is.”

I’m not saying you can’t do multi-threading or concurrency in C++. The problem is that it’s far too easy to get data races or deadlocks by making subtle syntactical mistakes that the compiler doesn’t catch. pthreads does nothing to help with that.

If you don’t need to share any data across threads then sure, everything is easy, but I’ve never seen such a simple use case in my entire professional career.

All these people talking about “C++ is easy, just don’t use pointers!” must be writing the easiest applications of all time and also producing code that’s so inefficient they’d probably get performance gains by switching to Python.

Your graph also cuts out early. Eventually you want to get performance gains with multi-threading and concurrency, and then the line drops all the way into hell.

deleted by creator

He absolutely has not.

There are two big problems with the point that you’re trying to make:

1. There are many open source projects being run by organizations with as much (often stronger) governance over commit access as a private corporation would have over its closed source code base. The most widely used projects tend to fall under this category, like Linux, React, Angular, Go, JavaScript, and innumerable others. Governance models for a project are a very reasonable thing to consider when deciding whether to use a dependency for your application or library. There’s a fair argument to be made that the governance model of this xz project should have been flagged sooner, and hopefully this incident will help stir broader awareness for that. But unlike a closed source code base, you can actually know the governance model and commit access model of open source software. When it comes to closed source software you don’t know anything about the company’s hiring practices, background checks, what access they might provide to outsourced agents from other countries who may be compromised, etc.

2. You’re assuming that 100% of the source code used in a closed source project was developed by that company and according to the company’s governance model, which you assume is a good one. In reality BSD/MIT licensed (and illegally GPL licensed) open source software is being shoved into closed source code bases all the time. The difference with closed source software is that you have no way of knowing that this is the case. For all you know some intern already shoved a compromised xz into some closed source software that you’re using, and since that intern is gone now it will be years before anyone in the company notices that their software has a well known backdoor sitting in it.

You have a talent for metaphor.