Hacker News Reader

Comment by emerongi | Hacker News Reader

I think the only question that matters is how much longer it takes to write a moderately-sized program in Rust vs C. If it takes around the same time, then an average C programmer will probably write code with more bugs than an average Rust programmer. If it takes longer in Rust, the Rust programmer could start taking some seriously unholy shortcuts to meet a deadline, therefore the result could be worse.

All code can have bugs, it's mostly just a question of how many. Rust code doesn't have to have zero bugs to be better than C. It's not like all C programmers are top-tier programmers and all Rust programmers are the bottom of the barrel.

View on HN

This is part of the issue though:

Writing things in C correctly takes more time than in rust (once you get past the initial learning curve)

Writing things in C that appear to work may take less time.

I think we can be reasonably sure that Apple didn't introduce those image parsing bugs intentionally. But that means they thought it was correct.

I've written a few things at work in C/C++ and Rust. I can move much faster in Rust, personally, as long as the pieces of the ecosystem I need are there. Obviously I only speak for myself.

Part of that is because I'm working in code where security is constantly paramount, and trying to reason about a C or C++ codebase is incredibly difficult. Maybe I get lucky and things are using some kind of smart ptr, RAII and/or proper move semantics, but if they're not then I have to think about the entire call chain. In rust I can focus very locally on the logic and not have to try and keep the full codebase in my head

That assumes that writing unsafe code would make you go faster. It wouldn't. In general if you want to write code in Rust more quickly you don't use unsafe, which really wouldn't help much, but you copy your data. ".clone()" is basically the "I'll trade performance for productivity" lever, not unsafe.

Reply on news.ycombinator.com