In Defense of C++

Terrible article.

> you can write perfectly fine code without ever needing to worry about the more complex features of the language

Not really because of undefined behaviour. You must be aware of and vigilant about the complexities of C++ because the compiler will not tell you when you get it wrong.

I would argue that Rust is at least in the same complexity league as C++. But it doesn't matter because you don't need to remember that complexity to write code that works properly (almost all of the time anyway, there are some footguns in async Rust but it's nothing on C++).

> Now is [improved safety in Rust rewrites] because of Rust? I’d argue in some small part, yes. However, I think the biggest factor is that any rewrite of an existing codebase is going to yield better results than the original codebase.

A factor, sure. The biggest? Doubtful. It isn't only Rust's safety that helps here, it's its excellent type system.

> But here’s the thing: all programming languages are unsafe if you don’t know what you’re doing.

Somehow managed to fit two fallacies in one sentence!

1. The fallacy of the grey - no language is perfect therefore they are all the same.

2. "I don't make mistakes."

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues.

Not true. As I said already Rust's very strong type system helps to make applications less buggy even ignoring memory safety bugs.

> Yes, C++ can be made safer; in fact, it can even be made memory safe. There are a number of libraries and tools available that can help make C++ code safer, such as smart pointers, static analysis tools, and memory sanitizers

lol

> Avoid boost like the plague.

Cool, so the ecosystem isn't confusing but you have to avoid one of the most popular libraries. And Boost is fine anyway. It has lots of quite high quality libraries, even if they do love templates too much.

> Unless you are writing a large and complex application that requires the specific features provided by Boost, you are better off using other libraries that are more modern and easier to use.

Uhuh what would you recommend instead of Boost ICL?

I guess it's a valiant attempt but this is basically "in defense of penny farthings" when the safety bicycle was invented.

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues.

Even if we take this claim at face value, isn’t that great?

Memory safety is a HUGE source of bugs and security issues. So the author is hand-waving away a really really good reason to use Rust (or other memory safe by default language).

Overall I agree this seems a lot like “I like C++and I’m good at it so it’s fine” with justifications created from there.

I think this is a case of two distinct populations being inappropriately averaged.

There are many high-level C++ applications that would probably be best implemented in a modern GC language. We could skip the systems language discussion entirely because it is weird that we are using one.

There are also low-level applications like high-performance database kernels where the memory management models are so different that conventional memory safety assumptions don’t apply. Also, their performance is incredibly tightly coupled to the precision of their safety models. It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t. A lot of new C++ usage is in these areas.

Rust to me slots in as a way to materially improve performance for applications that might otherwise be well-served by Java.

> It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t.

Can't agree there. Why wouldn't they be usable if they weren't memory safe?

Can you give me an example of this mythical "memory safe in practice" database?

Not Postgresql at least: https://www.postgresql.org/support/security/

Database kernels have some of the strictest resource behavior constraints of all software. Every one I have worked on in vaguely recent memory has managed memory. There is no dynamic allocation from the OS. Many invariants important to databases rely on strict control of resource behavior. An enormous amount of optimization is dependent on this, so performance-engineered systems generally don’t have issues with memory safety.

Modern database kernels are memory-bandwidth bound. Micro-managing the memory is a core mechanic as a consequence. It is difficult to micro-manage memory with extreme efficiency if it isn’t implicitly safe. Companies routinely run formal model checkers like TLA+ on these implementations. It isn’t a rando spaffing C++ code.

I’ve used PostgreSQL a lot but no one thinks of it as highly optimized.