[adwn]

There's nothing fast about zero-terminated strings. In fact, many operations on them are much slower than sane alternatives, because they first have to scan the entire string to compute its length. You can't even create a temporary substring without either modifying or copying part of the original string. How lame is that? Zero-terminated strings are almost never the best solution, so why are they the language-supported default?

> You should be thinking in assembly, [...]

Well, then you shouldn't by typing in C, because Undefined Behavior coupled with modern C compilers will make sure that what you get is not what you thought. *cough* signed integer overflow * cough*

> You can't push bytes through the hardware at its speed limit without getting your hands dirty

Rust proves you wrong (maybe some other languages, too, but I don't know them as well)

[creativemonkeys]

What you're missing is the difference between known issues and unknown issues. You're looking at a language that's been heavily used for 60 years and accumulated a long list of known issues and things not to do, that powers pretty much everything in computers, and you're comparing that with the new kid on the block with a vocal fanbase.

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 - but out of sight, out of mind, right?

As far as runtime speed goes, assuming equal instructions being generated, if Rust spends even one CPU cycle checking array lengths, its generated code will be slower than C's, by definition. You can justify the trade-off ("it checks array lengths for me because I am human and I forget sometimes") or relax the restrictions ("it's not humanly noticeable"), but you can't claim it runs faster or even just as fast, because it's not.

The only thing Rust proved to me is that there was a whole generation of developers who did't mind writing unreadable Perl code who had kids that are equally unaware of how unreadable Rust code is and it'll take a few decades for them to see that, assuming that Rust stays relevant for another decade.

[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.