FrankHB (frankhb1989.delete@this.gmail.com) on July 12, 2021 10:08 am wrote:
> 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.

mozilla-central is one of the oldest FOSS C++ codebases around going back over 25 years. One of the reasons why it doesn't use all of C++ latest features is that it's unfeasible unless you restrict yourself to very recent compilers. A lot of decisions in the past about which features to use were driven by compiler support and the need to support multiple C++ compilers. Since we started using clang exclusively (but we still accept patches to support other compilers) we've picked up a number of more recent features. However introducing them is often not simple and requires a lot of manual intervention on the codebase. Compare this to Rust where using new feature is often a simple matter of running clippy on the code; something we can do in automation with no user intervention.

> I believe this dude is not that good at C++, or even any other PLs.

Knowing him, if he'd really be not that good at C++ then everybody else must have been terrible. But more seriously, "being good" with a specific language in order to write decent code is an argument against the language rather than for it. To me it's really a matter of ROI; Rust is by far the language that allowed me to write better code WRT the time I spent learning it (which is not much really).

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

Oh yes it does! Mostly because one your code compiles you're pretty sure that it works, or if it does not fails in a fully controlled way that is easy to debug. And that's not taking into account all the niceties that make your life easier such as truly nice cross-platform abstractions, exhaustive and terse error-handling, a rich and pragmatic standard library, a build system that Just Works™, excellent tooling including auto-formatting... I might go on for a while.

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

Rust makes this a lot easier IMO, especially WRT ownership and error-handling which are two of the most difficult things to get right in C and C++. For example assertions are rarely needed because the type system allows you to fully control what gets in and goes out of a function.

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

Yes, absolutely. But that's also the reason why it just makes sense to use it. It's better in many respects because it's not bound by legacy and design decisions made in the late '70s. And I'm sure that ten or twenty years from now someone will come up with an even better language because of the same reasons. Lessons learned are important.

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

Among those things I really don't understand why people keep bringing up the lack of a formal spec. Seriously, Rust has incredibly good documentation when C and C++'s specifications haven't even been public for a ridiculously long time. And in spite of the presence of a formal spec C and C++ compilers have systematically implemented divergent behaviors which lead pretty much any non-trivial codebase to have compiler-specific provisions in order to work (and require compiler-specific testing!). That's without even going into thorny arguments such as the debate around strict aliasing where a large portion of the language users preferred to ignore a part of the spec and deliberately chose a non-standard option because it worked best for them.

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

We've obviously got little data about that - for now - but what we got shows that Rust codebases age much better than C++ ones. Mostly because of the tooling which makes it very simple to modernize old code, remove problematic patterns and exploit new features.

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

Do you have practical examples to prove this?