... please form an orderly line on the right.

Google is already been sued for this very thing..

There was a paper about rust use in open source projects, looking at vulnerabilities introduced by developers with different contribution histories. They suggest that you need to spend working several years in a C++ codebase to get down to the same defect rate as a new contributor in a rust project.

https://cypherpunks.ca/~iang/p...

If that is true, then there is probably little reason to worry.

The interesting thing is more productivity while reducing the number of bugs. Normally reducing bugs requires stricter processes, which typically reduces productivity.

Yes, that's exactly what I did,

I'll be very interested to find out whether the gimp snap has the same problem as the Firefox snap: it does not work in a VNC session. Like at all. There's a known workaround involving futzing some environment variables, but it is not a complete solution: although it gets the main Firefox window to come up, additional popups (like the Save As dialog) are still broken.

This was always a problem right from the beginning, since Ubuntu replaced its native Firefox package with a snap, 2-3 years ago. Initially I grinned and beared it, expecting the issue to be fixed soon. It is still not fixed, and nobody appears to be interested in fixing it. When I brought this up on the Ubuntu users list I got a very indignant response from a snap advocate, along the lines of "it's not a snap problem, it's a [some-obscure-library-related-to-desktop-integration] problem". Well, wonderful, but it's a distinction without a difference. The bottom line is that the Firefox snap does not run in a VNC session, and which specific library is responsible for the problem is a distinction without a difference.

There is increasing pressure on companies to take responsibility for their software products. This includes preasure to move towards memory safe languages. This exercise is about getting C++ of the governments naughty lists, so that people can continue to use C++ without extra regulatory overhead and too much risk to the company.

Rust is just a working example of a language with similar performance to C++, whise approach could be copied. The committee opted to not do that and go for something that does not make the language memory safe at all, but that catches enough bugs to be close enough (they hope).

We'll see whether that is implementable, practical and enough to satisfy regulators.

I have hunted my fair share of core dumps in Qt code. Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe. It does not, there is so much more needed... check what the "safe C++" proposal set out to change, that's what you need tomdo to make C++ memory safe using the approach rust took. It includes fun stuff like new reference semantics, destructive moves and a new standard library.

The new employee who's supposed to link to dupes didn't show up for work today.

The biggest problem are the platform ABIs that are not expressive enough for either rust or C++. That means both sides do tricks to smuggle extra information through the C-compatible platform ABIs -- or to pass constructs entirely around that ABI. E.g. name mangling is used to smuggle function overloading through the C ABI by encoding type information into the symbol name which is just a string.

Things going around the ABI is all the stuff that C++ requires to always be in a header file. Those headers get directly included into the user of a library, going around the ABI layer completely.

The challenge for interoperability is to extract all the necessary information from one language and make that available in the other. Gathering that information without some defined ABI means extracting it from the source code of the language itself. That is damn hard, especially if one side is C++ that needs heuristics to even get parsed.

There is a proposal to have Rust semantics in C++. Nothing more. It will take decades to get that through the committee, with prominent members already having said that all other venues need to be explored before this proposal can be considered.

Sean having suggested to not have a new C++ standard library (but to use rusts instead) is not going to help find support inside the committee.

So the problem is that you got devs that are unwilling or unable to learn new things? That's indeed a problem...

They will suck out the will to live from any fresh blood that joines their team. Your product is stuck in the past forever, behind a strong waöl of "we never did that before".

Yeap, but humans just can not do that. We need tools to help us.

... and yet that is exactly what the "Safe C++" proposal is that has hit the committee recently.

We are pretty much the only industry that thinks like that. There is no contradiction between "improve eco system" and "train developers". All the other industries around us do both.

We are also pretty unique as an industry in that we watch our products fail and then go "there is nothing we can do about that, sucks that random people were too stupid to write proper code". We urgently need to improve, or we need regulators to step in to make us improve. Code is just getting too important to continue with our attitude.

Memory issues are used to attack your software. Them causing crashes is the lucky case...

True, but those languages make sure you do not need to worry about the entire class of bugs that are related to memory management.

That frees up resources to think harder about all the other issues your code might have.

Rust has proven that you can eliminate these issues without runtime overhead. So fixing these issues is now considered by governments to be low-hanging fruit.