This is one of those "...except when it does" takes. It's always been a bald faced No true Scotsman fallacy.

A: "Modern C++ has no problems with memory safety." B: "But what about X? X was written in C++ last year. X has problems with memory safety." A: "X is not modern C++."

That "memory unsafe languages produce vulnerabilities" is an empirical claim. I can give you gobs of data. If you actually think, "In practice, people writing modern C++ code do not struggle with memory safety", then you should produce some data that shows this to be the case.

So, my take is -- okay, prove it. Because, my guess is, your claim is mostly a feeling you have about your code (yes, simply good code vibes) rather than something you can demonstrate to others.

> In practice, people writing modern C++ code do not struggle with memory safety, so it has been a good trade.

Then why do we have so many memory safety bugs in, for example, modern webbrowsers? I'm relatively sure that the Chrome team is pretty competent, and yet...

The Chrome team is evidently not writing modern C++ code.

"No true Scotsman...". Take string_view for example: perfectly cromulent modern C++. I use it daily to reduce the number of unnecessary copies. It's also very easy to code a use-after-free bug with it.

Only by storing it somewhere. So long as it is only passed down a call chain, no problem.

string_view really is no different from a naked pointer. Modern C++ treats naked pointers with well-deserved suspicion. I never have any trouble because pointers are always strictly evanescent values.

> In practice, people writing modern C++ code do not struggle with memory safety, so it has been a good trade

So you believe then, that the majority of C++ code written at e.g. Microsoft is not 'modern'?

Quote from [1]: "~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues."

[1] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

> So you believe then, that the majority of C++ code written at e.g. Microsoft is not 'modern'?

Maybe some new code is modern - but there is a tremendous legacy code base that can’t possibly be (and Microsoft has released enough open source that you can verify this yourself). Also retrofitting isn’t magic - the boundary between old and new will always cause problems.

Note that while MSRC asserts that, Azure Sphere OS and Azure RTOS only support C (not even C++), and WinUI team likes to boost themselves how much of the underlying COM components are written in C++ (in UWP some of them were .NET Native).

Also Visual C++ team is quite keen in brigging Rust like safety (as much as possible) to their static analysis tooling.

Have you seen WINAPI?

Microsoft coders are, as a rule, notoriously bad, always have been.

Are you implying that all past and current Microsoft employees are bad coders?

Obviously not. But an enduring large fraction are, and remain. And code there is practically never improved or modernized, only patched onto. It is a cultural thing: there is no perceived value in anything but new bullet-item features.

Rust requires you to write correct code. And no, lots of people using modern C++ do struggle with safety, and specifically memory safety. That's why these new languages exist, and exactly why they are gaining users every single day. No matter what someone on hacker news says...

This doesn't mean c or c++ are bad or something. But, yea...

Rust does not, in fact, require you to write correct code. No language can do that. The best a language can do is make it harder to write certain kinds of incorrect code. And, libraries coded in a powerful language can do that, too.

You are right it does not gaurantee correctness. Libraries can also provide unsafe or incorrect code. C++ lacks a package manager and a community mindset. So I trust c++ library's less than many modern programming languages...

Rust makes it so you can do this yourself for most things. It's not always convenient but it's the best I've seen so far.

I'm interested to see how automatic formal verification of rust code is going. Super interesting area, think a team at AWS is working on it, and a few other groups.

Conan, vcpkg and NuGET already cover a lot of C++ workloads nowadays.

Yes there are several third party package managers, which is a pretty good smell that the situation is sticky at best. Out of the three my favorite is NuGET. Unfortunately the ecosystem last I checked anyway was weaker than say rusts' or go's(at the risk of comparing apples to oranges). Python also has multiple package managers, and the worst part of python when used appropriately is it's package managers and logical layout...

Most modern programming languages have one package manager dedicated to the language, and for good reason imo.

Part of the problem is, the c++ culture is kind of like the c culture, most people would rather write their own packages from scratch then leverage a community. I don't blame the languages, they were around before git was common.

I feel like I am bashing c++... I don't mean too, it's a great language and it does have good packages(some I prefer over what is available in say Rust), but most projects I've seen not using visual c++ do the 1990s thing and don't use these tools. Maybe it's their age, never looked hard at "why", being honest.

Surely it is weaker if we are counting npm like quantity of packages.

If on the other hand we are counting quality packages, all major ones are available.

I was going to write a diatribe on rusts great features, but I don't have time.

Please go try rust, not for its memory safety but for all of its other qualities that make it better than c++ in my book.