tobias12345

True, you have few external dependencies... but you have random code thrown into your repository in the form of vendored 3rd party libraries, header only libraries, and bits and pieces copied from somewhere. Of course you also get huge kitchen-sink libraries that do everything, so you only need to add one library and have semi-decent functionality for everything you might need. At least those usually have people working on maintaining their usually pretty huge dependency tree -- those they know of. They have the same problems knowing their true dependency trees as everybody else in the eco system.

I have not yet looked at any C++ code base > 1 milliom lines where I did not find at least 3 copies of zlib. Often just the compression or decompression function copy and pasted into a random file. Which version? No idea. Was it patched? Likely. Is there any documentation on how to update this? Absolutely not. Was it easy to find? No, some specialists even rename the functions so that users linking to the system zlib do not get into symbol conflicts. I have heared way to often that it is so much simpler to just copy a class over from abseil, or whatever other library than to depend on it.

Sure, you do not see dependencies, the functionality those provide are still there somewhere though -- either hidden away or in the form of reimplementations. You just do not know... and what you do not know about you can not maintain.

To handle supply chain attacks, you need to know where yiur code comes from. That is often not a given when working with languages where it is easier to copy and paste in code from random other projects.

I have seen so must stuff copy and pasted into projects in my life, its not funny. Often it is undocumented where exactly the code comes from, which version it was taken from, how it was changed, and how to update it when something goes wrong.

When code is not copy and pasted it is over rewritten (poorly).

Code sharing does have its benefit. So does making it obvious which exact code is shared and how to update it. Yes, you can overdo code sharing, but just making code sharing hard on the tooling level does mote to hide supply chain security issues than it does to prevent the problem.

I doubt that ideomatic code is easier to write in C once you switch to Fil-C. Your code will just get killed by the runtime whenever it does something it should not do (and the compiler does not catch). You need to think about that stuff when your runtime enforces it.

"Memory safe" means that there are no memory safety issues. One of the most critical areas targeted by exploits is just gone. And this in turn leads -- according to the numbers published by Google -- to a severe reduction of exploitable issues.

C++ means you can not know whether code is safe or not. That does not mean it is unsafe, but assuming it is is the only sane way to handle this. Incidentally this is exactly what browsers do: They typically require two out of these three to be true for any new piece of code: "written in a memory-safe languge", "sandboxed" and "no untrusted inputs". This blocks C++ from some areas in a browser completely.

Yeap, systemd is just another init system existing on a level playing field. They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.

How will porting a single concept like `defer` from zig, a language that is not memory safe, to C and C++ make those memory safe?

`defer` is a poor man's RAII. C++ has had RAII since the beginning, and C++ is still not considered memory safe. So how will adding `defer` help C++ to become memory safe?

This feels like another example of how poorly C and C++ devs understand the ideas behind memory safety. You do not really need to understand this concept, as long as you can debug all the memory issues that just pop up:-)

> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.

How so? By listing all dependencies in an easy to digest way?

Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it.

"Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done.

Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository).

Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there.

> Currently I see no existential risk at all.

I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed.

When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.

Sean Baxter stated that he is not working on Safe C++ anymore, so that proposal is dead.

But is somebody still working on safety profiles? I have not noticed and profiles related paper seeing updates since Hagenberg. Herb just wrote in his trip report "Profiles papers received a lot of discussion time in EWG (language evolution working group) and feedback to improve consensus,", which leaves any interpretation open.

Does it matter whether it is a common class of bugs or a not so common one? The point is, this is a class of bugs you do not have when picking a different language.

C++ claimed for decades to be about eliminating a class of resource management bugs you can have in C code, that was its biggest selling point. So why is eliminating another class of bugs a nice to have now?

C++ is loosing projects to memory safe languages for decades now, just think of all the business software in Java, scientific SW in python, ... . The industry is moving towards memory safe software for decades now. Rust is just the newest option -- and a very compelling one as it has no runtime environment or garbage collector, just like C++.

This has been going on for over a year now. Any progress in C++ land towards more memory safety?

Nope, editions cover that use case nicely: Rust breaks things every three years -- without breaking existing code.

Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.

Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.

RAII is great, but unfortunately it breaks down when the resource it manages leaks out of the RAII type.

E.g. Whenever handing out the raw pointer stored in a unique_ptr, the code receiving that raw pointer can delete it, which will very likely lead to a use after free and certainly to a double free issue.

I am not arguing that there is a lot of C++ code and that this code will be around for a long time. But I would prefer to see C++ as a language with a future and not as the language some well-paid dinosaurs use to keep the legacy code-base running while all the cool stuff happens elsewhere. "C++ will make a great legacy language" is underselling it.

But we might be wrong: Some government or consumer org or something _could_ step in and start to require the use of memory safe languages or just discourage the use of C/C++ in anything they buy. That would hasten the replacement of C++. I am afraid this is getting more likely based on how the C++ community handles growing concerns about memory safety outside of the development communities.

I have seen presentation on safety by people I respect for their contributions to the C++ language that all said a combination of these things:

* you said "C/C++", so you must be clueless * you do not know what safety means, let us explain that to you * everybody else does it wrong and is not really secure either * we can not solve the problem, because everybody uses C++ for the tricky bits that other language can not do because they are oh so safe * other languages are not as safe as they claim as they can all call into C++ * it will act swiftly, it will probably only take us a decade or so * you can use some extra tools somehow, that somebody will probably write * asking devs to follow our recommendations has never worked before, so we need something to enforce things. Let's ask all devs to please use this new thing. * Devs unfortunately do not follow best practices and there is nothing we can do about that

That does not seem to be a very convincing communication strategy to me, even less so when other communities show that real improvements are possible.

So your argument is: C++ will be a great legacy language and we will enjoy its memory bugs for decades to come?

I really hope it can do better than that.

Note that Window ships a kernel driver written in Rust already, Linux (== ChromeOS and Android) are working to add rust support and iOS is moving towards Swift everywhere. Other languages are closing in on all the use cases you mentioned.

There is more out there than C++ and Rust, but yes, if you are stuck with C++, then you have no option but to wait for a couple of years and start to rewrite wehn C++ is ready.

I seriously hope all your competition is in a similar situation or it might become harder and harder for you to meet requirements going forward. The push towards memory-safe languages is out there.