Rust lacunae [LWN.net]

Rust lacunae

Posted Jun 11, 2021 10:08 UTC (Fri) by khim (subscriber, #9252)
In reply to: Rust lacunae by ncm
Parent article: Rewriting the GNU Coreutils in Rust

> All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite, at much less risk of introducing new bugs, and without abandoning those targets LLVM poorly serves.

Unfortunately the time have come to accept that C and especially C++ are not languages you can use to write bug-free programs. Even if your code is bug-free today it wouldn't be bug-free tomorrow. Modern compilers insist that code compiler with --std=c89 or --std=c++98 should obey rules introduced in 2023 (sic! they use not yet developed and not yet approved rules from not yet existing standard to compile code written decades ago — look here for details). With C you can piggyback on the Linux need to actually produce reliable code and the fact that Linus keeps one (just one) C compiler in a state where it can actually be used for that. With C++ that's just plain out impossible.

Rust is built on the same unstable foundation, but, fortunately, this quicksand is only for the unsafe part of the language, safe mode (the default mode) is supposed to not have any undefined behaviors which compiler couldn't detect. This make it actually suitable for reliable software.

> No Holy Mission drives such activity, so we see it happen with resounding success in Gcc and Gdb, but not yet in less active projects, or in more hidebound ones like PosgreSQL, SQLite, Git, Systemd, the BSDs, or Linux.

Linux already contemplates Rust, too.

> Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another.

Modern C++ is unsitable. You can't write safe software using it. Simply because you never know how and when code style would be retroactive changed. Google writes such code in C++, but it's special: they “own” both sides of the equation and thus can actually change code-which-was-safe-but-is-now-unsafe when they are changing the compiler. Most C++ developers don't have such luxury. And since Linux doesn't use C++ they couldn't rely on Linus, too.

> Rust users place in their compiler and in audited "unsafe" blocks in their corresponding libraries.

Rust tries to make sure that code written according to the rules of the book is not only safe today but would stay safe tomorrow. That's big practical difference. The fact that this promise doesn't cover unsafe code is quite unfortunate, but typical rust project doesn't include a lot of unsafe code thus there are at least some hope. No such hope with C++, sadly.

> It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason

C++ maybe more convenient and sometimes even offer faster code (with the use of rvalue-references and other such things) but they also make it more bug-prone. Time have come to start thinking about abandoning it. And Rust is the only viable alternative.

And I say that as someone who likes C++ and hates Rust syntax. Bug I guess I would have to accept it.

to post comments

Rust lacunae

Posted Jun 12, 2021 9:29 UTC (Sat) by ncm (guest, #165) [Link] (6 responses)

You can repeat "unsuitable" until you turn blue. Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

Thus, every tiny increment in safety of C++ code being written, from any cause, whether via compiler improvements, language evolution, standard library improvements, third-party library improvements, new libraries released, or developer education, *each* have overwhelmingly more real-world impact than the entire output of the entire Rust ecosystem, from language spec through to "hello world" beginner. All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.

Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better, and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.

You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself. In another decade, you will likely have discovered some other enthusiasm of likely similar real-world impact.

I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.

Rust lacunae

Posted Jun 12, 2021 10:33 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

> Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust.

Sure. And they would be buggy and there would be lots of CVEs and data loss. That's fine: if safety is not your goal, data loss is accetable and only performance matters to you then C++ is fine choice.

“Unsuitable for any purpose” is definition from some “better world” position. Where people are more honest and care about security and not just about security certificates. We don't live in that world, sadly.

Indeed. Only you misrepresent direction. Today programs written in C++ code are worse from security perspective than it was yesterday and tomorrow they would be even less safe. Just look on number of CVEs in Chrome, e.g. Yes, 2020 had less vulnerabilities than 2019 — but that's mostly because COVID-19 made development slower. And 2021 is shaping to beat record of 2019, so…

Also note how DoS vulnerabilities have disappeared. That's good, right? C++ is doing great, right? Nope: it just means that there are so many other, more serious, vulnerabilities that DoS ones are no longer even worth reporting.

> All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.

Indeed. Pain accumulates slowly but steadily. And even Google and Microsoft are thinking about abandoning ship (and before you misinterpret me: no, they are not ready to embrace Rust, Google have just only added it to Android… even the decision whether to drop C++ or not is not yet finalized… but discussions are underway).

> Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better,

That I agree with.

> and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.

That I couldn't agree with, sorry. While C++ can be improved it's actually less secure than C code. Simply because language is just so complex and insecure. And most mitigations techniques (sanitizers, static analysis, etc) improve safety of both C and C++ thus C stays ahead.

Heck, if you compare C and C++ standard you will find out that C have (and always had) four nicely-prepared lists in it's annex: unspecified behavior list, undefined behavior list, implementation-defined behavior list and locale specific behavior list.

With C++… after 36 years of developers we only have proposal… and it doesn't even includes such lists, it just says that it would be nice to, you know, have an actual list of rules for the programmer to follow somewhere.

That's not security, that's a joke.

> You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself.

Only time will tell. Rust was added to Android only just one year ago. And only couple of small subsystems were implemented in Rust. Microsoft joined the Rust Foundation and actually supports development in Rust, but is not yet ready to drop C++.

But the fact that these companies with billions of investment in C++ tools, lots of in-house expertise and their own compilers (clang's C++ is basically Google work at this point, Apple never was all that interested in C++ and other contributors do even less) are even contemplating switch says you something about C++ safely, I'm afraid.

Yes, it's true: we don't yet know if Rust would be able to replace C++ or not. But the fact remains: it's the only relatively popular language that can do that. C#, Go or Java are all very nice languages but they couldn't be used as low-level system languages. Rust can be used for that.

And it's more secure than C, unlike C++, which is less secure, so why would you advocate switching to C++?

Rust eliminates certain classes of bugs entirely (not all of them, of course, you can write buggy code in any language) while C++ warmly embraces latter choice in the infamous “Hoare dilemma” (There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies).

Thus if you need security you go with Rust. If you only need security certificates then C++ is better for now. But why would anyone want a security certificate for coreutils replacement?

Rust lacunae

Posted Jun 12, 2021 23:51 UTC (Sat) by ncm (guest, #165) [Link] (2 responses)

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 7:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

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

We already know whether Rust will displace C++. It will. Any plans you have that depend on not 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.

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.

Rust lacunae

Posted Jun 13, 2021 18:30 UTC (Sun) by Wol (subscriber, #4433) [Link]

> You can repeat "unsuitable" until you turn blue. Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

> I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.

You only observe and report reality? Like the future? Well they do say prediction is always difficult, especially if it's about the future.

It won't take much, and you could suddenly find all those thousands of pages you describe are legacy. There's probably *still* more Cobol than C++ in regular production use, but nobody hears about it because it's all in maintenance mode. What will you say if that description becomes true of C++ in the next decade?

Cheers,
Wol

Rust lacunae

Posted Jun 28, 2021 13:38 UTC (Mon) by immibis (subscriber, #105511) [Link]

> Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

This was true of every now-dead language, at some point.