Comment by hyperman1 | Hacker News Reader

Comment by hyperman1 | Hacker News Reader

As ssoneone who used to like C++ but has moved on to rust: There are good things in here, but I am not convinced they go far enough, even if completely implemented.

The good: I see a new Stroustrup. At the time of the NSA report, he seemed to be in denial about the position C++ was in, security wise. The 'just be carefull'- wont-scale slide seems a much better basis to start the discussion from.He seems to propose something similar to rust editions, allowing problematic parts of the language to be switched off, with an escape hatch similar to unsafe.

If this would work out, rewrite it in rust could no longer be needed. There is an upgrade path for C++, and an incentive to use it.

The bad: There seems to be still some denial in there. I see rust providing today what he calls a fantasy. In fact, it existed before C with languages like ADA, except the ecosystem just wasnt there. Second problem is the timeline. 3 years for a new language version, then 10 years for the ecosystem to upgrade, then another 10 years until everyone is convinced this new way of working should be better? It seems both an aggressive timeline and a promise it wont happen in my professional lifetime. Also, a path forward is not a commitment, e.g. to completely eradicate undefined behavior outside unsafe blocks.

All and all, and I hope I am wrong here, I read this as too little, too late. Rewriting it all from scratch is hard, but erasing the culture of the C++ ecosystem seems a lot harder.

Bjarne Stroustrup's major problem, that people keep forgeting about him is that he isn't a BDFL of C++, rather a very important WG21 member with the vote of one person.

So while his opinion is highly regarded by some of the ISO WG21 300+ voters, like in politics, if he doesn't manage to win the majority of the voters, and then the compiler writers (which can always ignore part of ISO, and they sometimes do), it hardly matters.

As for the three years, while it may seem a long time, keeping up with six week releases on Rust is also not a panacea, and when Rust eventually gets more than just a reference implementation, like required by law in some industries, it will also slow down.

As example in some of those industries, being able to use certified C++14 or C11 toolchains is already a luxury.

Rust solves some problems of C++ (memory safety for common-cases of code) while introducing new problems (less expressive safe code and harder-to-write unsafe code, expanded UB when trying to expose &mut to safe code from raw pointers, or RefCell runtime panics).

I don't disagree about unsafe Rust being trickier than people might realize, but "RefCell runtime panics" bring a "new" problem is a bit of a stretch; it's strictly better than UB, which can also crash. Making a situation that used to be "maybe crash, maybe accidentally continue running and make things far wise than crashing" instead "definitely crash" is a reduction of an existing problem rather than a new one.

RefCell causes runtime panics in cases (holding onto a borrow or borrow_mut() for too long) where C++ has well-defined behavior (two pointers can reference the same memory and both be valid for reads/writes).

This statement…

> "maybe crash, maybe accidentally continue running and make things far [worse] than crashing" instead "definitely crash"

…is functionally indistinguishable from your reply.

> (two pointers can reference the same memory and both be valid for reads/writes).

So, you're taking a "statement" from another person to "prove" that person you're replying to is wrong without adding any substance to your comment? What person you're replying to said is nothing wrong. Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary. And funnily, in some cases, it chooses to terminate or bring down the whole program in runtime because of that.

> Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary.

Rather than forbid, Rust requires you put logic like this inside unsafe blocks. This limits the number of places you need to look for UB. Hopefully the number of shared writable pointers is not excessive.

C++ programs on the other hand are all the equivalent of one big unsafe block. That's the difference, not anything "forbidden" by Rust.

"To look for" is a very vague and imprecise definition because that's not how you actually write or test your software. You don't look for UBs. It doesn't change the fact that you still have to hunt for bugs using ASAN, UBSAN, TSAN or MSAN _runtime_ sanitizers. This false dichotomy is following Rust since ever.

CloudFlare remade their primary reverse proxy in Rust and had so few development issues, they ended up finding kernel bugs instead when problems arose. I've worked on projects with non-trivial C++ codebases for a variety of companies, large and small, and with some excellent developers who are far more skilled than I likely will ever be.

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

A non-trivial C++ codebase with that kind of track record is so rare as to be unheard of, though many can approach it with the various sanitizers plugged into the dev workflow after the fact.

C++ has improved dramatically over the last fifteen years, but a lot of stuff simply can't be fixed without breaking backward compatibility, which just isn't going to happen.

We've had enough time elapse to see the related rates of CVEs posted for C++ and Rust apps over the last few years. It's not even close.

It is absolutely possible to have bugs in a Rust app due to logic error or memory leak. But C++ has those same limitations and so many more unless you tack on a host of add-on analysis tools and still you end up with a result that is not as safe as Rust.

Write a web app server in Rust? Sure. As long as I know the problem space, have the dev time allocated, and the need for that efficiency is clear.

Write it in C++? Hell no. Not ever again. Not in a million years. Even if the need for efficiency is demonstrated, I have far less confidence in the integrity of that service when connected to the public internet, no matter how skilled the team is.

Even Scott Meyers—Scott Fucking Meyers, who wrote acclaimed books on advanced use of C++ we mere mortals came to depend upon—does not have confidence in writing code for it anymore. In just three years, he went from an undisputed authority on the topic to this in 2018:

"As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action."

https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...

Neither I nor the folks I have worked with were as skilled as Scott Meyers at his prime, and the majority of us—myself especially—aren't even as good as he was 2.5 years after he stepped away.

Perhaps you are. Are you certain that everyone else on your team is? Everyone who comes later that has to maintain those codebases?

With Rust, I believe teams have a fighting chance. With C++, I'd just as soon buy lotto scratchers since I'm looking at similar odds. Perhaps I'm just an average software engineer. That's entirely possible, and I'll cop to that. But I'm not alone, and we still have bills to pay and code to write. For the sake of my clients, that'll be in Rust before C++ if I can help it. (And neither if the problem doesn't require their level of efficiency.)

You're constructing your own and very biased reality which you use to derive conclusions. Twice in this thread. Wasting other people time. OTOH I was genuinely trying to give out a different perspective on something you may have not thought about and whose answer could imply that your reasoning is probably not quite correct. However, you're working really really hard for a conversation not to converge by making up bad examples and beating around the bush. Scott Meyers got nothing to do with my comment so does not CloudFlare, which btw has a major outage as of today.

> Cloudflare is assessing a loss of power impacting data centres while simultaneously failing over services. [1]

A major power outage has nothing to do with reverse proxy software. It's difficult to take your critiques in good faith.

C++ is too complex for an expert to safely identify whether something is a bug or not. Not all C++ developers are experts. It is alarming you consider this state of affairs to be acceptable or that Rust does not clear mitigate many of these issues out of the box.

Does Rust eliminate all bugs? Of course not. That was never the assertion. When Microsoft finds in a study that 70%+ of all Microsoft CVEs would have been avoided given Rust's memory model, it should not be hand-waved away as personal preference or irrational bias. [2] [3]

[1] https://www.cloudflarestatus.com/incidents/hm7491k53ppg

[2] https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst...

[3] https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-sy...

> A major power outage has nothing to do with reverse proxy software.

I am glad you recognize how bad of an example that was. Now apply this to the rest of your arguments.

> or that Rust does not clear mitigate many of these issues out of the box.

You're again imputing something I never said only to support your opinion. This is the third time in this thread you're successfully avoiding to address the substance of my initial two comments. I won't proceed any further in this discussion because it's a plain waste of time.

> that's not how you actually write or test your software. You don't look for UBs.

In Rust, it absolutely is. You generally have so few `unsafe` blocks that it's entirely reasonable for a human to audit them and manually verify that their invariants are upheld. You can still use tools like Miri if you want even more assurance, but that's optional.

Even if such thing would be possible to do by a bare a look at the code, which is most certainly not, it's still unclear to me how would you do that in a non-trivial, let's say, 1M LoC codebase. Or how do you make sure that none of your 3rd-party code even holds to that promise? Although noble that is unreachable goal.

UB does not happen because there's few lines of code that do the wrong(TM) kind of obvious thing but it happens because that chunk of code interacts with other parts of the code in ways that you usually cannot conceive without tooling or realistic workloads.

I guess that for that or similar reason, Rust also happens to be working on adding support for UBSAN, ASAN, TSAN and MSAN sanitizers. Unfortunately it has been WIP for almost 7 years: https://github.com/rust-lang/rust/issues/39699

RefCell runtime panics are UB. All of Rust consists of behavior for which the international standard imposes no requirements. The set of requirements imposed on Rust by international standard is a null set.

I'm sorry for being pedantic, but it's important to distinguish between UB generally (which would normally be termed "implementation-defined" in common parlance if that weren't already a term of art) and memory safety specifically.

We don't get CVEs because a C source file didn't end in a newline. I suspect we rarely get CVEs because someone failed to add -ftrapv when they should have. We get CVEs primarily due to OOB memory access.

> All of Rust consists of behavior for which the international standard imposes no requirements.

This is quite the... unique way of defining "undefined behavior". Rust is currently implementation-defined. That doesn't even remotely mean its behavior is undefined in theory. And it certainly doesn't mean that "all of Rust" is UB in any practical, real-world sense. In practice, your average Rust program is more well-defined than nearly every C codebase, in terms of what invariants the compiler is allowed to assume about the code for the sake of performing transformations (which is what UB actually means, rather than "is there an international standard").

It isn't unique. That is the one and only definition of "undefined behavior" as a term of art.

Many cases of UB in C are perfectly well defined at the implementation level. Some are not, for reasons ranging from lack of a demand signal, to the need for an expensive runtime, to compiler writers wanting to squeeze out every last drop of performance.

Reply on news.ycombinator.com