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

Linus Torvalds is a god in Linux community. People just defend his decisions for no reasons. Of course they hate C++ for no reasons.

The funniest joke is https://lwn.net/Articles/764664/ nonsense. Deliberately use the identifier class to break C++, even in the user space.