4 ms·
Because the reason C/C++ codebases are getting hacked is not primarily because they're written in C/C++, its because they were written a LONG time ago when secu
by zaptheimpaler 5y ago
Because the reason C/C++ codebases are getting hacked is not primarily because they're written in C/C++, its because they were written a LONG time ago when security didn't matter so much, the entire industry was much less mature and it was probably way harder to code, and management at companies would probably never allocate any time to a non-issue like that.
Its just so completely uninformed and noob-ish to equate _tools_ to what people build with them. The language is not nearly as important as the programmer and the context in which the code was written. Its a very typical new-programmer thing to think language is all that matters, but most programmers with a few years experience understand how little it matters compared to everything else. You guys are basically like those old Christian missionaries who show up somewhere in Africa knowing nothing and insist the locals convert. Totally clueless..
- mrich 5y agoIf we are starting to get snarky: There are two kinds of people who choose Rust over C++. Beginners who think C++ is too hard, and seasoned developers with years of experience working in large teams who _know_ C++ is too hard to get right.
- zaptheimpaler 5y agoive been learning Rust and it doesn’t seem like the clear win fans say it is. i recently ran into a variant of this problem: https://doc.rust-lang.org/nomicon/lifetime-mismatch.html https://doc.rust-lang.org/nomicon/lifetime-mismatch.html i know the lifetimes are fine, but Rust doesn’t. in a memory unsafe language i would have to model the mutability in my head to ensure the code is fine. i now need to model the lifetime checker and its limitations/false positives _in addition to_ the underlying mutability to understand whether a compiler error is actually a bug in my code or not. and this is in an extremely short & simple program. a compiler that can truly enforce safety without too many false positives is definitely a win. but for now it seems like a leaky abstraction so it adds complexity instead of reducing it.