Brendan (btrotter.delete@this.gmail.com) on July 12, 2021 2:34 am wrote:

> > Also recently I've found the stupidity like this:
> > https://github.com/Rust-for-Linux/linux/commit/c606d85a0d3c67b8221fee5fa67028bdebd4b0cc#diff-521fe5c9ece1aa1f8b66228171598263574aefc6fa4ba06a61747ec81ee9f5a3
> >
> >
> > Instead of doing this
> > void foo()
> > {
> > p[1].x().y() = p[2].x().y();
> > }
> >
> >
> > Now you have to do this. Who the fuck in rust team though this is a good idea.
> > ///SAFETY: p has 5 elements
> > ///XXXX
> > ///XXXX
> > unsafe fn foo()
> > {
> > (unsafe{p.get_mut_unchecked(1)}.unsafe {x()}.unwrap().unsafe{y()?})? =
> > (unsafe{p.get_mut_unchecked(2)}.unsafe {x()}.unwrap().unsafe{y()?})?;
> > }
> >
> > Rust one is completely unreadable, wasting programmers time and probably even leading to slower compilation.
>
> Unlike C++; where it's impossible to be sure what something as innocent looking as "a = b + c;"
> actually does without scouring the source code to determine who overloaded what; where compile
> times have a reputation for being the worst of any language ever created (despite scavenging the
> concept of modules from other languages and slapping it onto their huge pile recently)?

This is red herring. The example is about some crazy and absurd code abuse, which is also complaint by average Rust users. In constrast, operator overloading is quite idiomatic and irrelavant to the point here.

As of this C++ case, it should not cause trouble once the overloaded operator is well-designed to expose its intent properly. It is also ridiculous to blame the contextual-dependent nature solely of the overloading. The name lookup on variables "a", "b" and "c" also requires reading the declaration to ensure the meaning clear, so you are actually forbidden from being that innocent unless you don't use any languages having such kinds of scoped variables.

BTW, overloading, being a form of ad-hoc polymorphism, is certainly evil in many sorts. But in the context of C++, my hatred to the feature mostly comes from the effects that over-complicated overloading rules bloat the language specification (i.e. ISO/IEC 14882) a lot. As of Rust... well, where is the language specification?

And thanks to Rust, reputation of compile time of today's C++ seems to be promoted a bit. (I'm against C++ module for some other reasons, though.)

> > If the goal of Rust team is to make everything painful, why should I waste time to fight against
> > the compiler? Instead of using that time to sanitize and fuzz? What's the benefit of using it?
>
> Heh. This is how I feel about "smart pointers" in C++. If the goal of C++ is to double
> the (already 10 times worse) learning curve why should I fight against the compiler?

Why do you feel C++'s smart pointers difficult to learn? Is Rc really simpler than shared_ptr besides the spelling?

> Note: I'm not a Rust advocate (I'm just willing to let other people spend their time experimenting
> so I can obtain better empirical evidence about the benefits and pitfalls of certain language features).
> To me; the goal should be to reduce complexity of the language (because I think "more complexity" translates
> directly into "higher chance of mistakes" and that programmers have enough complexity to deal with
> from the problem their code is trying to solve), and to reduce the time between a programmer making
> a mistake and the programmer finding out a mistake was made (primarily by designing language to maximize
> the practicality and effectiveness of "continual analysis while you type").
>

Professional empirical evidence (in the sense of programming language theory and authoring the language specification) shows both C++ and Rust are the kind of most evil ones about both complexity of language rules and learning curves for most users. There do exist a few worse, say, Haskell; but C++ and Rust are already enough far from easy and simple for non-specialists. And they will both become worse in the forseeable future. I don't see the essential differences here, besides "disgned by commitee v. community".