Hacker News new | past | comments | ask | show | jobs | submit login

I think "not in control of what the compiler is doing" is overstating things a little bit. In some ways, Rust gives the programmer more control than C does. For example, Rust has standardized support for inline assembly, but inline assembly in C relies on vendor-specific extensions.

But to your point, the convenient defaults are very different. Unsafe typecasts require a lot of ceremony and careful thought in Rust, and they have to follow more rules than in C. In particular, references are all effectively "restrict" in Rust, and it's really easy to screw that up when you do unsafe cast from raw pointers to safe references, which is a big incentive not to write code like that if you have a choice.




> but inline assembly in C relies on vendor-specific extensions.

Whereas Rust is a standard with multiple implementations?


I should've said "stabilized" instead of "standardized" to avoid stepping on this conversational landmine. But an important practical difference is that Rust supports inline assembly on Windows. (Correct me if I'm wrong, but I think MSVC mostly does not support inline asm.)


It does support inline assembly [1]. However, it's different than the way GCC supports inline assembly. It seems nicer, TBH.

[1]: https://learn.microsoft.com/en-us/cpp/assembler/inline/inlin...


From that source:

> Inline assembly is not supported on the ARM and x64 processors.


Oh, my bad. I should have read the source more closely. I hadn't realized only 32-bit x86 processors were supported.


That's hilarious. Like, the compiler team had ONE GUY that believed in and developed this feature and retired in 1999.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: