[adwn]

> You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered

That's a bad argument, because it could be used against any change or improvement. By that logic, humans should have never even come down from the trees.

> if Rust spends even one CPU cycle checking array lengths

That's the thing: Almost all checks and guarantees which make Rust safer than C are done at compile time and have no negative effect on the generated code.

[creativemonkeys]

That's not a bad argument, it's a statement of fact. I'm using it to point out that using Rust carries risk, whether you realize it or not. Just because you've accepted the risk, doesn't mean it is a universally good decision and C is now bad. Maybe coming down from a tree pays off, maybe you get eaten by a jaguar.

People who don't put in the effort to really learn their tools, need tools with training wheels. It's perfectly fine for a language to put in checks to protect you against yourself and be "fast enough for practical purposes", just don't confuse "almost fast" with "always fast". Rust programs have to pay the price for runtime checks because Rust doesn't trust you to know what you're doing.

[samatman]

The first paragraph of this is weird coming from someone who claims to think assembler and type C. Do you realize, or no, that Rust and Zig use LLVM for release code (Rust uses it for everything)? What are these risks you refer to, looking funny?

> Rust programs have to pay the price for runtime checks because Rust doesn't trust you to know what you're doing.

Buddy, you talk a lot of game about knowing your tools. Don't say obviously ignorant stuff about other peoples tools, it makes me think you're bluffing about C.

[creativemonkeys]

To answer your question, I'm well aware of the backends used, but using LLVM doesn't mean that the same IR or assembler gets generated. Enjoy the rest of this weekend.