Rust (the language) hate thread

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Yeah, but that's the point. It means you can directly reuse machine code instead of performing a template operation or writing boilerplate.
You can have dynamic dispatch through trait objects. Not every trait is object-safe though, and object safety basically captures the necessary properties for this to work, eg. the type in question must be behind a pointer so that the generated machine code can work uniformly with any type, whatever its size and alignment. So this special case makes machine code reuse possible with the usually insignificant cost of indirect calls.

Everything goes through the vtables. But whereas C++ puts the vtable pointers inside the objects themselves, and this gets quite complicated with multiple inheritance and virtual inheritance, Rust uses fat pointers, meaning that the pointer to an object is paired up with the pointer to the vtable, so it's outside of the object itself. That's why I said there are no restrictions on the internal layout.
 
I'm pretty sure the results of comparing dangling pointer types is implementation-defined in C++ as well. Try doing it in C++: https://godbolt.org/z/7W8YzeEe5
Not quite sure what this is supposed to prove or disprove. This example has a typo on line 20, that make it appear as a and b have the same value, which they haven't.
Using a function instead of scope blocks (and ignoring the warning) makes sure the program uses the same memory block for both, after which both a and b are identical, printing true as the expected result.
Doesn't seem to me that C++ has this issue.
 
  • Like
Reactions: The Anarki Main
Not quite sure what this is supposed to prove or disprove. This example has a typo on line 20, that make it appear as a and b have the same value, which they haven't.
Using a function instead of scope blocks (and ignoring the warning) makes sure the program uses the same memory block for both, after which both a and b are identical, printing true as the expected result.
Doesn't seem to me that C++ has this issue.
Change that a to b and add -O2 to the (GCC) compiler options.
 
  • Like
Reactions: Max Free
Let me just give a small example:
Code:
struct ZeroSized;

trait Trait {
    fn method(&self);
}

impl Trait for ZeroSized {
    fn method(&self) {
        println!("lol");
    }
}

fn foo(object: &dyn Trait) {
    object.method();
}

let a: Box<ZeroSized> = Box::new(ZeroSized);
let b: Box<dyn Trait> = a;
foo(&*b);
Here ZeroSized is a zero-sized type, because it's a struct with no fields. a is a thin non-null pointer to a uniquely owned memory allocation, but because the pointee type is zero-sized there is no actual allocation and it's in fact a dangling pointer. b is a fat pointer which is just a paired with a vtable pointer. There is only one foo in the generated machine code, and it calls the trait's method through dynamic dispatch. It will happily accept the zero-sized object because it genuinely imposes no requirements on its internal structure.

What I really appreciate in Rust is that Option<Box<T>> is the same size as Box<T>, with Some(x) having the same representation as x, and None being represented by the null pointer. The same is true for references and other smart pointers. You pay zero cost in terms of space and the type system ensures that you cannot forget to check for the null-pointer case.

It's just so... sane.
 
Yeah, the troons can make a lot of goodness when they set their goal on something very legible and understood by-the-feel (in this case, “fixing C++”). I’ve seen them do this a lot with all kinds of software. It’s how you get people like Byuu.

I honestly think it’s plain schizophrenia at this point. You lurk in their stomping grounds and find them shockingly lucid within the narrow band of nerdshit they have claimed, but they are totally loaded and dangerous lunatics outside those bands. It’s not any different psychologically from Terry Davis – he made a beautiful operating system, but God was he out of his mind as for why he did it. The difference with him was that his insanity was walked alone, because rambling about God isn’t as cool as it was maybe 150 years ago. Making rotdogs and stinkditches is what society is falling over itself for, so he was born a bit too late for all of the kooky Protestant algal blooms that used to colour America over a century ago.

I don’t want to blow too much smoke up their asses, though, because then again none of this shit is revolutionary on a level like Einstein or the Unix guys. They don’t have the grounding necessary to achieve that kind of thing. They are, however, really good at optimising an existing space, like a giant toxic Markov chain array. It’s gross, but interestingly so.
 
Yeah, the troons can make a lot of goodness when they set their goal on something very legible and understood by-the-feel (in this case, “fixing C++”). I’ve seen them do this a lot with all kinds of software. It’s how you get people like Byuu.

I honestly think it’s plain schizophrenia at this point. You lurk in their stomping grounds and find them shockingly lucid within the narrow band of nerdshit they have claimed, but they are totally loaded and dangerous lunatics outside those bands. It’s not any different psychologically from Terry Davis – he made a beautiful operating system, but God was he out of his mind as for why he did it. The difference with him was that his insanity was walked alone, because rambling about God isn’t as cool as it was maybe 150 years ago. Making rotdogs and stinkditches is what society is falling over itself for, so he was born a bit too late for all of the kooky Protestant algal blooms that used to colour America over a century ago.

I don’t want to blow too much smoke up their asses, though, because then again none of this shit is revolutionary on a level like Einstein or the Unix guys. They don’t have the grounding necessary to achieve that kind of thing. They are, however, really good at optimising an existing space, like a giant toxic Markov chain array. It’s gross, but interestingly so.
You take Saint Terry's name out of your mouth, boy. Terry would hit these troons with his car. I think trannies infest programming because they're just autistic. You've got Boomer autists like Bjarne, and then you've got the nightmarish zoomer autists like the Rust trannies.
 
Change that a to b and add -O2 to the (GCC) compiler options.
I am not in favor or against C++, I'm just here to figure out what is going on. I ran it in GDB and looked at the assembly.
At -O2 the executable never calculates if a==b. The compiler stores the string "false" in the executable, and passes the string('s pointer) into the wifi password of a function call "_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_pkC@plt", but the executable never makes a decision about whether it should print "true" or "false".
What is particularly weird is that when printing a and b it passes the same register value to the function "_ZNSo9_M_insertIyEERSoT_@plt", and doesn't modify it in any way in-between. The compiler seems to know that the values of a and b are equal and optimizes them down to a single register, but still thinks that a comparison between a and b would resolve to False.
Very strange.
 
I am not in favor or against C++, I'm just here to figure out what is going on. I ran it in GDB and looked at the assembly.
At -O2 the executable never calculates if a==b. The compiler stores the string "false" in the executable, and passes the string('s pointer) into the wifi password of a function call "_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_pkC@plt", but the executable never makes a decision about whether it should print "true" or "false".
What is particularly weird is that when printing a and b it passes the same register value to the function "_ZNSo9_M_insertIyEERSoT_@plt", and doesn't modify it in any way in-between. The compiler seems to know that the values of a and b are equal and optimizes them down to a single register, but still thinks that a comparison between a and b would resolve to False.
Very strange.

printf version, which has more readable assembly: https://godbolt.org/z/5r41516Px

The answer's going to be because there's undefined behaviour. I'm not a rules lawyer, but presumably it's UB to use the pointer of a stack variable that's out of scope.
 
  • Informative
Reactions: MAPK phosphatase
I am not in favor or against C++, I'm just here to figure out what is going on. I ran it in GDB and looked at the assembly.
At -O2 the executable never calculates if a==b. The compiler stores the string "false" in the executable, and passes the string('s pointer) into the wifi password of a function call "_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_pkC@plt", but the executable never makes a decision about whether it should print "true" or "false".
What is particularly weird is that when printing a and b it passes the same register value to the function "_ZNSo9_M_insertIyEERSoT_@plt", and doesn't modify it in any way in-between. The compiler seems to know that the values of a and b are equal and optimizes them down to a single register, but still thinks that a comparison between a and b would resolve to False.
Very strange.
When invoking undefined behavior, anything the compiler outputs is legal, so in particular, a compiler can optimize under the assumption that UB doesn't happen. In this case, what I suspect is happening is that GCC reasons that pointers to objects of disjoint lifetimes cannot possibly be equal and therefore (a == b) ? "true" : "false" can be simplified to "false". It could similarly reason that they cannot possibly be unequal (since it'd be UB to compare them either way), but "can't be equal" is probably more useful in practice since it gets rid of aliasing issues.

IIRC it's because even accessing the value of a pointer is UB once it has been freed/etc, so an implementation could e.g. set them to NULL afterwards.
 
As a rule, I strongly dislike anything with layers of abstraction beyond that of C, except for Lisp. But I can see why others would like other lower level languages like C++ or Rust.

I like having the power to fuck shit up and make my own potentially poor choices. I have written multiple emulators and a miner for a calculator in pure assembly, for no other reason than finding it fun. This principle extends to multiple other areas of life outside of computing, but I'll stay focused. Any kind of "feature" that introduces a noticeable level of hand-holding usually only ends up irritating me. I find these often involve trade-offs where things become either wildly convoluted and counterintuitive, or way too simplistic to the point of severely retarding any power, flexibility, and usually readability. C++ is probably the best at avoiding this, but I'm too set in my ways to make much use of it. Stuff like dynamic typing only causes me headaches; I don't get the appeal. It's one of the many reasons trying to poke through and follow the source of projects like pytorch often requires flipping between 4+ files at a time. Js makes this a massive problem, but that's only a drop in the ocean of issues with modern web dev. If you ever want me to go on for the length of "War and Peace", ask me what I think about js and web as a whole.

All of the dictatorial tranny bullshit only further deters me from using anything made by people born too late to remember what it was like to have the freedom to make your own decisions. I typically don't engage with any other programmers outside of some old irc buddies anymore. Almost every refuge from normies I have ever held dear has been taken over by fur fags and troons. I wouldn't give a fuck if they didn't demand the ability to put their degeneracy on the forefront. Shame used to keep society much more sane.

All of this said, I make a point of having a good grasp on these languages. I don't expect everyone to share my brand of weapons-grade autism. I think Rust has some really cool ideas, and I have used it off and on since before it had a decent standard library, but it's never my first choice. I feel like Rust's main appeal is only relevant to those who can't be trusted with pointers (i.e. paid iOS internals devs). Sadly, this always becomes a big problem unless you maintain former Linus level control over your projects, and most understandably don't have the time, energy, nor patience to do so. Old curmudgeons like myself are on the way out—that's life.

As an aside, I find whitespace languages like Python only encourage a lack of flexibility in formatting to the point of autistically dictating how others view the author's code in a single, usually dogshit, way (see PEP 8 and co.). I seem to remember a bot on github a while ago which made PRs that comply with PEP 8 for anyone who dared to think different™. I won't ignite the flame war, but I think code isn't your fucking ascii art project. It's not like AI devs and such make very readable shit in the first place.
 
Not quite sure what this is supposed to prove or disprove. This example has a typo on line 20, that make it appear as a and b have the same value, which they haven't.
Using a function instead of scope blocks (and ignoring the warning) makes sure the program uses the same memory block for both, after which both a and b are identical, printing true as the expected result.
Doesn't seem to me that C++ has this issue.
Rather late, but you can just fix the typo and add -O2 as another reply mentioned.
 
The compiler seems to know that the values of a and b are equal and optimizes them down to a single register, but still thinks that a comparison between a and b would resolve to False.
These posts explain the issue very well (and they apply to both Rust/C++/any language with similar memory models):
- Pointers Are Complicated, or: What's in a Byte?
- Pointers Are Complicated II, or: We need better language specs
- Pointers Are Complicated III, or: Pointer-integer casts exposed

The gist is: pointers are not integers. Or at least, the compiler doesn't see them that way.
Semantically, pointers are opaque objects that point to... somewhere. The exact location is not defined.
Due to optimizations, such as those which attempt to reduce function frame size, or just due to how the final assembly is generated the location of two pointers may end up pointing to the same "physical" memory location. They also might not.
However, to the compiler the pointers still point to different memory locations. From the view of the compiler, int x in the first and second scope are still separate objects. And so the compiler will conclude that "pointers" A and B do not refer to the same object and hence A != B.

Arguably it's a miscompilation since in the example A and B aren't actually pointers but integers, which I agree with since it can lead to very unexpected results.

FWIW, Rust has guaranteed_eq.
 
It still boggles my mind how Rust is taken so seriously, even by large corporations and the US govt. It was a research language and still is in many ways. Instead of consolidating and making a spec, they keep on adding more and more language features. Look at the mess than is async, the majority of Rust users seem to hate it.

The idea that Rust is safe is a stretch; who the fuck knows if some piece of code has undefined behavior, you would have to look at the compiler source code.
 
The idea that Rust is safe is a stretch; who the fuck knows if some piece of code has undefined behavior, you would have to look at the compiler source code.
The phrase "undefined behaviour" doesn't even make sense for Rust, as there's no spec. The whole thing is undefined behaviour by definition.
 
It still boggles my mind how Rust is taken so seriously, even by large corporations and the US govt. It was a research language and still is in many ways. Instead of consolidating and making a spec, they keep on adding more and more language features. Look at the mess than is async, the majority of Rust users seem to hate it.

The idea that Rust is safe is a stretch; who the fuck knows if some piece of code has undefined behavior, you would have to look at the compiler source code.
If Rust were memory safe (which many misguided investors seem to think it is,) it would be the only low-level language that AI chatbots would be able to write "safe" code in without the application segfaulting during runtime. This, I suspect, is a major reason behind the push for Rust adoption.
 
Rust is the systems programming language for betas. The borrow checker and the compiler tells you how to write your code and the memory model is so restrictive it might as well have a GC. That explains the number of troons and femboys using it and why so many of them are attracted to rust even when they aren't doing systems programming. It also explains why plugins like `cargo-mommy` are so popular - rust programming already involves submitting to cargo, so you might as well make it explicit.
 
The troonery is now embedded in Rust's build system.


The Git / cargo project in question.
That video doesn't even reveal the true purpose of the plugin (or whatever it's called). If you check this page, you can see that it has an NSFW mode. Of course, it's fetish crap without it, but this is how it works at full power.

Even worse, it's apparently compatible with this plugin, which incorporates the buttplug API thing. There's an interesting issue on there too.
1738327280233.png
 
Back