Rust lacunae
Rust lacunae
Posted Jun 12, 2021 9:29 UTC (Sat) by ncm (guest, #165)In reply to: Rust lacunae by khim
Parent article: Rewriting the GNU Coreutils in Rust
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.
Posted Jun 12, 2021 10:33 UTC (Sat)
by khim (subscriber, #9252)
[Link] (3 responses)
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. 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). That I agree with. 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. 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?
Posted Jun 12, 2021 23:51 UTC (Sat)
by ncm (guest, #165)
[Link] (2 responses)
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.
Posted Jun 13, 2021 7:28 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
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.
Posted Jun 13, 2021 18:30 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
> 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,
Posted Jun 28, 2021 13:38 UTC (Mon)
by immibis (subscriber, #105511)
[Link]
This was true of every now-dead language, at some point.
> 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.
Rust lacunae
Rust lacunae
Rust lacunae
Rust lacunae
Rust lacunae
Wol
Rust lacunae