Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on July 14, 2021 2:28 pm wrote:
>
> 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.

So, the quality issue is mostly for historical reasons, not specific to the concrete language. This is not typical enough to show the differences between the languages.

Note I don't mean it is necessary to update the required language version to get the latest features available. AFAIK Mozilla-central is routinely tied to a quite small set of versions (if not a specific version; usually not latest, but also not too old) of the C++ toolchain targeting Windows. There are regular efforts to make updates work. However, updates of the build environment might fail, at least I've seen the attempts to move it to MSYS2 and to WSL died suddenly on the half way. This implies there may be quality issues unrelated to C++ code. There should be also something else (in the sense of engineering or project management) preventing a steady progress to make the codebase just work with some language versions (e.g. C++11 onward) without too many toolchain-specific patches. Using Rust does not magically make the underlying problem disappear; it just allows a simpler policy about the concerning toolchain updates, because there is only one vendor of the Rust toolchain and one "tip" (in hg parlance) of the language versions in production, hence less compatibility issues. Nevertheless, the actual improvement about the whole experience is limited (if not worse), because the dependency of the C++ toolchain is not removed; then you may have to deal with C++ + Rust (+ Python...) problems rather than merely C++ (+ Python...) ones.


>
> > 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).
>
"Being good" with knowledge strictly specific to C++ is usually unnecessary. The most important points for programmers to learn in practice are definitely shared among multiple PLs. In particular, the ownership semantic is very important for both C++ and Rust users. While many C++ users are not enough educated in this area, Rust users often learn the essentials by fighting with the borrow checker in the compiler. For users not already familiar with the principles about the ownership rules, the Rust way can save much time. This is not always a good thing, because users are too encouraged to rely on the language implementation without sufficient caveats. Some other less-known knowledge is also important, but not easy to be identified with the help from the compiler; sometimes the compiler is even totally clueless by design (e.g. the compiler cannot tell users the confidently safe policies/criteria to use the "unsafe" keyword). Users who relying on the compiler too much may be not self-disciplined enough to handle such problems well, so there will be naturally more risks on the code quality and more pressure on the project management.


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

Well, the nice tooling is a certain benefit, the design is not. Sometimes not even more "correct" than C++.

For example, the abuse of explicitly fixed-width machine numbers in the basic type system is totally against the abstraction purpose: consider the fact you should not have many chances to have an exactly fixed-with integer like "i32" in the real business logic (expect for some low-level [de]serialization works between some on-wire formats and some in-memory representations), you're routinely making the conversion unconsciously to fit the semantic gap between the code and the real design implicitly. Such implicity is dangerous before you leak "i32" to the design, and then you totally failed to abstract details like "32" away. (Rust certainly won't insert any check between the gap of "i32" and the_real_type_you_need_in_the_design!)

And compared to exception handling, the typical error handling mechanism in Rust is somehow enforcing the designers of API to go against separation of concerns, because the error information is always forced explicitly (equally significantly to the non-error "workloads") in the type signature of API (also often bad for ABI compatibility, but this is an implementation detail).

Such glitches are often not obvious for most users, making it even more error-prone in everyday programming. I don't expect my life easier working with these users.

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

Decreasing the need of the assertions for the contracts is promising, but I suspect it not feasible in the long term, because the type system is still to weak to express many things a user of interface may be interested in. And once ABI compatibility is concerned, it will be further limited because the cost of update of API can be significant. It is already an improvement to current C/C++, but I'm not sure it will perform better than C++ contracts in future.

There are some other uncertainty. The popularity of the idiomatic use is significant one. As we have known, C++ has the improvement of built-in non-nullable references besides the nullable pointers, but many C++ projects still avoid pointers in the interface even they are never nullable (and always non-owning). Thus, there is no actual improvement. I see Rust having less similar problems, though.


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

Lessons are learned inefficiently in the industry. I'm not too patient to wait for the changes.

For a motivation, I have already hit the performance bottleneck of stateful allocators in C++ due to too much register bandwidth consumed by the parameter passing, compared to simple replacing malloc by LD_PREOLAD. The allocator is necessary not just for performance reason, so I can't replace it by malloc. And there are apparently other problems to use namespace-scope or thread-local variable to hold the allocator. To mitigate the problem, using some opted-in dynamic scoped variable should be a good choice. But this way is just hard to hack (in the sense of the design, not only the implementation) within ALGOL-like languages. Other languages allowing easier hacks usually rely on GC, which mostly defeats the purpose to having an allocator.

I'd make up my own languages, anyway.

> > 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.
>
Well, lacking of a formal spec is not a big deal because the language is already complicated enough and a formal model will not ease the analysis on program semantics too much. However, it is particularly useful to formally prove the expected properties of the type system (e.g. soundness), and it is a solid basis to extend the type system.

I am more interested in the normative spec: the clear unambiguous criteria of some implementations to be Rust (the conformance rules). This is not only useful to authors of alternative implementations, but also for users who want to derive the specification to get some other modified designs of the language, i.e. hacking the language design.

ISO C and ISO C++ are not shared in the spec-level except a few references to the C standard library in the C++ standard library. Most fundamental rules, like the base type system, or even the definition of "implementation-defined behavior", are totally rewritten, although (1) there are many things mentally compatible or even exchangeable between ISO C and ISO C++; (2) ISO C++ seldomly makes changes almost verbatim merged back to ISO C (like "sequenced before" v. "sequence point", and the concurrent memory model).

A proper example of deriving a language from existing one is ECMA C++/CLI to ISO C++. The spec of C++/CLI only specifies the features not in ISO C++. This is far easier than maintaining a spec in parallel to ISO C++.

There are certain risks of fragmentation to encourage derivations of a programming language. But I don't think Rust can get everything just right in its official design, so having some divergent versions from the origin (namely, the dialects) may provide some locally better design choices to test for users who need them, which is also not bad for the remaining users.

Users of the divergent dialects should afford the cost of the code divergence. This is similar to the fact that C++ does not need to take care the decisions of C++/CLI, in contrast to the mess of mutually involved ISO C/C++ liaisons. Note that provided a spec, I don't think the divergence of unspecified behavior among conforming implementations a big problem; you already have them when there is only one implementation (since the reference cannot make everything as exact as the implementation, and there can be divergence between different versions).

Anyway, without a spec, it is even impossible to measure the fragmentation itself, and there are still the same risks after some unpredictable fork of the Rust's toolchain repo.

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

I don't know what kind of practical examples you want exactly.

The compromises mentioned above are all facts easy to see: you have no enough resources so you choose to skip to finish the spec; you have no resources to maintain the complicated C++ rules, to harmonize them to existing language rules and to take the risks they do not work well finally, so you do not support the some features as C++ (even if they can be coexisting consistently)... The reason I take the alternatives not in the current Rust "better" is in the sense that any work to explore the possibility is better than nothing (besides the decision of premature quitting the experiment), even the resulted design can have other problems.