Rust lacunae [LWN.net]

Rust lacunae

Posted Jun 12, 2021 23:51 UTC (Sat) by ncm (guest, #165)
In reply to: Rust lacunae by khim
Parent article: Rewriting the GNU Coreutils in Rust

We already know whether Rust will displace C++. It won't. Any plans you have that depend on displacing C++ have already failed, right out of the gate.

It doesn't matter what you agree or don't agree with; nobody asks you.

Instead, they continue to choose to use C++ because it works, is fully mature, yet is on a cycle of continuous improvement. It reliably brings in billions of dollars, quarter after quarter, for myriad serious users. They invest in continuous improvement by sending literally hundreds of representatives to ISO Standard meetings three times a year, more at each meeting than at any prior, to help prepare the next Standard. Each Standard published on a reliable 3-year schedule has had as much work than the sum total ever devoted to Rust.

I have spent strictly more time in the past decade filing bug reports against compilers than I have in chasing down memory errors in my C++ code. So, whatever Rust has to offer in avoiding memory errors is of no practical value to me or people who code like me: we don't make memory errors. Overwhelmingly more of us are coding C++ than have ever even heard of Rust. More pick up coding C++ anew each month than the total who have ever so much as compiled hello.rs.

You can pretend all you like that C++ code is less secure than C, or that it is getting less secure, or that Google et al. are preparing to drop it, but it is your fantasy. Your need to invent falsehoods to promote your case only shows you have no case, and that people have been correct to ignore you.

Rust lacunae

Posted Jun 13, 2021 8:43 UTC (Sun) by farnz (subscriber, #17727) [Link]

In at least one large engineering organisation I'm aware of, Rust is displacing C++ in internal tooling, and there are people looking at using it in customer-facing code because the internal tooling that's written in Rust has the performance characteristics of tooling written in C++, but with many fewer bugs, and all of those bugs being either non-security or in the FFI layer to existing C++ libraries that are being reused.

I would not bet on Rust displacing C++ in the next 5 years; I also wouldn't bet on C++ retaining dominance in the next 20, because the Rust ownership and borrowing model is the killer feature over C++17 (the current internal standard for C++ in that organisation). And the problem with the ownership model is that it needs full ecosystem buy-in to be useful - everything has to respect it in order for it to give benefits - which means that a C++23 with a Rust ownership model will take decades to upgrade existing C++ code to the point where it's useful.

With Rust, because there's a clear FFI boundary (e.g. using the CXX crate), you get tooling assistance in enforcing the model at that boundary, and with experience, it becomes clear when a bug is in the FFI layer or C++ code, and when it's in Rust.