Discussion on: Is modern C better then Rust?

[James [Undefined]]

First of all, you still didn't say what Rust enums look like in memory, so I think that point still stands(I didn't say that they are not stable).

The part about not being stable is the important part, as it's not really possible to know exactly how a (#[repr(Rust)]) enum looks without looking at the compiler. (And even then, layouts can still be randomized as Rust makes no guarantees about the layout of structures and enums in #[repr(Rust)], though it can guarantee that for #[repr(C)].) Generally, for unions without data, it's a byte. For unions with data, it's a tagged union with a byte for the discriminant and the data as an inline union. Note that as padding is not strictly defined, it may be arbitrarily bigger to align by platform-specific aligning rules. I don't know what they look like in #[repr(C)] but I'm sure it's somewhat similar and probably is in the Nomicon.

An unstable ABI for enums makes it really nice for things like Option<&T>, because references are internally pointers (at the machine code level), so None can be represented by a null pointer, so it only takes up the size of a pointer, not the size of a pointer plus one. This single byte can add up and also due to alignment it may be padded to 2, 4, or even larger amounts of bytes which affects performance and memory usage.

Second of all, it never happened to me to have such code that doesn't resemble what I wrote, but from what I heard it can happen from time to time. If you have a problem like this then a good solution would be to search what things the compiler might optimize.

Sure, that's fine and probably is a normal experience. I was kind of exaggerating, I guess. But still I don't think it's really necessary to know what your code will look like at the low level, as long as that low-level code is just as fast as you would expect. And Rust, for the most part, is. (There's still a lot of improvement to be done here, though too!)

I strongly disagree with this sentence: "If you need to code in assembly, code in assembly.", writing in assembly takes too much time and is even more error prone than C. C was made to be a portable assembly

Sorry, that was phrased badly. What I meant is that if you need the precision of specific assembly instructions, perhaps you should just use assembly.

I know that having a language feature is very nice, but what I am saying is that you can still do that in C. Many people say that they don't use C for this reason and I wanted to show them that C is not as obsolete as they think.

I absolutely get that! C is by no means obsolete, and it probably won't be for a while; but there are still new features that are in other languages like Rust that add on to C and make it (relatively) easier and much safer to write low-level code.

I didn't say that references are slow or bloat, I said that the way they work doesn't really fit in the low level programming. When I did some low-level programming in Rust I felt like I was spending more time on how to use refrences(not learning, just integrating them in the project) then the project itself, tho I can see why they are very useful for making desktop applications and stuff like that.

Sorry, I misunderstood what you meant as you didn't explain on that. I feel that the way they work absolutely works for low-level programming because it allows you to have fairly precise access over memory while not sacrificing memory safety. There are only a few places where you need to use raw pointers in Rust over references, and most programmers in Rust, even lower-level ones, I'd say, very rarely have to use raw pointers. Especially because there are APIs over pointers like Pin that allow certain features with unsafe but without the error-prone raw pointers.