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.

▲

MBCook 5 days ago | parent | next [-]

> 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.

▲

jandrewrogers 5 days ago | parent [-]

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.

▲

IshKebab 5 days ago | parent | next [-]

> 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/

▲

jandrewrogers 5 days ago | parent [-]

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.

	▲	IshKebab 4 days ago \| parent [-]
		Ok but can you give one example? You can micro-manage memory in Rust if you really want so I'm not sure why this would be a factor.

▲

oytis 5 days ago | parent | prev [-]

Rust is a systems programming language, it was absolutely designed with the second use case in mind.

▲

jandrewrogers 5 days ago | parent [-]

This is true. But it has some weird gaps that make it difficult to express fundamental things in the low-level systems world without using a lot of “unsafe”. Or you can do it safely and sacrifice a lot of performance. I am a fan of formal verification and use it quite a lot but Rust is far more restrictive than formal verification requires.

Rust is a systems language but it is uncomfortable with core systems-y things like DMA because it breaks lifetime and ownership models, among many other well-known quirks as a systems language. Other verifiable safety models exist that don’t have these issues. C++, for better or worse, can deal with this stuff in a straightforward way.

	▲	IshKebab 4 days ago \| parent [-]
		> without using a lot of “unsafe” You are allowed to use a lot of `unsafe` if you really need to. How much `unsafe` do you use in C++? > it is uncomfortable with core systems-y things like DMA because it breaks lifetime and ownership models, Sure, it means it can't prove memory safety. But that just takes you back to parity with C++. It feels bad in Rust because normally you can do way better than that, but this isn't an argument for C++.

▲

oytis 5 days ago | parent | prev [-]

Fallacy of grey, now I know how is it is called. I see it used by C++ programmers to dismiss Rust a lot.

Nobody claims that Rust is a perfect language, the argument is that Rust is a better language than C++.