Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on July 12, 2021 1:31 am wrote:
> You really don't wanna go there; in Firefox we've got a large body of Rust code and it's exhibiting
> a fraction of the issues our C++ code suffers from. And those issues are usually trivially simple
> to address precisely because Rust's unsafe parts can be isolated. Additionally - if you'd be looking
> for another reason to use Rust - the parts of our code we have rewritten usually take 5-to-10 less
> LOCs than the old C++. Heck we've rewritten Python tools in Rust yielding less LOCs than the original.
> And that's not even touching things like robustness, memory usage and performance.
>

Sorry, but under the impression the overall quality of mozilla-central is rather awful. I was shocked many times when I forked the codebase for my personal builds of the browser (because at that time I need the support for both XUL and WebExtensions addons and no upstream candidates worked with my existing profiles). Since the quality of the aged codebase is so poor, I don't think it a fair case to show the Rust-specific pros by code rewriting from C++ to Rust. I guess a rewriting to "modern" (whatever the concrete style it actually to be) C++ should also have more or less similar effects on LOCs if the paid employees of Mozilla are capable to that work in a sane way. Actually, some serious source bloats are fixed by simple and idiomatic C++ quite easily, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1141431. Rust won't do anything essentially better.

Python, on the other hand, is another big source of headaches (esp. the build system), as well as the project management (like randomly picking useless components in the main branch and then throwing them away in some later releases) ... But it is just another story.

> Citing an article from a former colleague about the first project he wrote in Rust from scratch:
>
>

Much of my work using Rust has been on the Rust compiler itself, but that mostly involves
> making small edits to existing code. fix-stacks is the third production-quality Rust
> project I have written from scratch, the others being Firefox’s new prefs parser
> (just under 1000 lines of code) and counts (just under 100 lines of code).

These are relatively simple tasks in realworld production code. There should be no too big differences to write a component of a compiler frontend using idiomatic C++, Rust, or even JavaScript, once it works.

> My experience in all cases has been excellent.
>
> * I have high confidence in the code’s correctness, and that I’m not missing edge cases that
> could occur in either C++ (due to lack of safety checks) or Python (due to dynamic typing).
> * The deployed code has been reliable.
> * Rust is a very pleasant language to write code in: expressive,
> powerful, and many things just feel “right”.
> * I have been writing C++ a lot longer than Rust but I feel more competent
> and effective in Rust, due to its safety and expressiveness.
> * Performance is excellent.
> * As mentioned above, the entire fix-stacks project wouldn’t
> have happened without the third-party Symbolic crate.
>
> Rust gives me a feeling of “no compromises” that other languages don’t.
>
>

Emphasis mine.

I believe this dude is not that good at C++, or even any other PLs. The real value of Rust's methdology is to ease programmers on reviewing others' code (comparing to the case that most C++ users are poor on the coding skills and reviewers have to spend a lot of efforts to make the code as expected). It does not ease much in the coding otherwise, as claimed here.

I'd take the emphasized bullets to illustrate the points above.

First, It is the programmer's responsibility to maintain the sane contracts in the code. Lacking of safety checks is the normal case. In C++, to widen a contract (in the WG21 parlance) is a bad practice, so C++ users are obliged to insert build-specific checks like assertions where the compiler cannot enforce the contracts, in their daily work. This is somewhat laborious and Rust has some limited improvents here (via the typechecking), but there is no execuse to miss it. Explicit typechecking on dynamic types are the widen version of this discipline.

Second, most C++ users may very likely have bad habits and intuitives on the coding style. Not all are their wrongs. Instead, many are the tech debts of the C++ source compatibility to C. For example, C++ textbooks traditionally teach the new-expressions before higher level resource management facilities like allocators and smart pointers, so users will likely to have "new" coming first in their mind when they need to allocate a new resource (object). This is bad because "new" should normally be the feature of last sorts, because all other facilities are more specific to the concrete intents and only "new" breaks the some important invariants (non-leaking guarantee, basic exception safety...) by default (not that bad in C because there are not many better choices, though). Noobs will hardly have these basic insights by themselves, no matter how long C++ they write. And I don't think feelings of most users are useful due to this reason. Nevertheless, in this sense, Rust deserves do better.

Third, there are many compromises in Rust. To list a few: missing the normative language specification, missing a formal semantic model, missing the proper tail call guarantee, missing the orthogonality on the mutablity and the sharing property on objects, missing the ability of user-defined side effects on parameter passing, missing non-local control operators, etc. Some are so obvious that if some user does not realize any of them, I'd suspect he/she not familiar with the language enough.

> Actually Rust has already proven many times over that it's better than C++. In production environments,
> both in the FOSS and closed-source world.

I doubt if it will be in a better situation after aged Rust codebases are spread almost everywhere like C++ today.

> C++ and C are languages that were designed in the
> past century; with concepts and technical limitations from a different time and without the
> accumulated experience we have now. While they evolved over time their evolution is slow due
> to their large legacy and how their evolution happens (design-by-committee).

Ironically, all the compromises mentioned above except two (missing a formal semantic model and missing the PTC guarantee) are accidentally better done in C++ than Rust. What a great evolution in this century!

> Why do you call "stupidity" making a large chunk of code safe? Weren't you the one saying that
> too much of that code was unsafe? Or maybe you didn't know that the body of an unsafe function
> is not unsafe by default. You seem unable to understand how unsafe code works in Rust.

I'm not particularily interested in this case, but I'd like to say the simple dialectical way of looking at the safety guarantees seems one of the serious sources of stupidity. Why on earth memory leaking is (absolutely?) excluded from such "memory safety"? (Fortunately, both C++ and Rust at least do better than those "GC languages" at this point...)