4 ms·

> I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get

> I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care. I don't agree, specially considering legacy code. Those of us still have to deal with an awful lot of code written 10 or 20 years ago still have to maintain code that juggles pointers and references around in ways that are hard to track ownership, and migrating this code to C++11 is no simple task. This doesn't mean people don't care. It just means the industry cannot afford getting whole teams to spend a couple of years on sabbatical to refactor legacy code and pay it's legacy debt. This is perhaps the biggest strawman that Rust fanatics use to criticize all things that isn't written in Rust. They pick their small little greenfield modules and boast how safe and perfect it is, and proceed to criticize all legacy production code whose teams can't even spare time to fix long standing bugs, let alone pay off technical debt. And that's somehow something Rust fixes?

pjmlp 4y ago
This security fanatic keeps seeing greenfield code written exactly like that, today. I also preach against "C with C++ compiler" since around 1994. Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.
- simplotek 4y ago
  > Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms. See, this is yet another instance of the strawman argument I pointed out. This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things. Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.
  - pjmlp 4y ago
    With enough liability laws, the resource allocation gets sorted out. Of course there are exploits in safer systems languages, memory corruption issues and arithmetic exploits only represent 70% of root causes. We still need to consider the remaining 30%.
  - spoiler 4y ago
    Can you give concrete examples?
    - Jweb_Guru 4y ago
      They can't. Rust has been way more secure than C++ in the wild.
spoiler 4y ago
Sure, the language hasn't been around for that long, but that doesn't invalidate the fact that there are large codebases written in it, and that maintained projects in Rust regularly keep up to date with language advancements, though. Another benefit of Rust is that you can largely avoid the same category of monster codebases common in C++, because there's much less (virtually none) friction in splitting up your codebase into crates. Like SURE... You CAN do this in C++, but it's usually just simply not worth the bother, because you gain next to nothing

pjmlp 4y ago

This security fanatic keeps seeing greenfield code written exactly like that, today. I also preach against "C with C++ compiler" since around 1994. Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.

simplotek 4y ago
> Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms. See, this is yet another instance of the strawman argument I pointed out. This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things. Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.
- pjmlp 4y ago
  With enough liability laws, the resource allocation gets sorted out. Of course there are exploits in safer systems languages, memory corruption issues and arithmetic exploits only represent 70% of root causes. We still need to consider the remaining 30%.
- spoiler 4y ago
  Can you give concrete examples?
  - Jweb_Guru 4y ago
    They can't. Rust has been way more secure than C++ in the wild.

spoiler 4y ago

Sure, the language hasn't been around for that long, but that doesn't invalidate the fact that there are large codebases written in it, and that maintained projects in Rust regularly keep up to date with language advancements, though. Another benefit of Rust is that you can largely avoid the same category of monster codebases common in C++, because there's much less (virtually none) friction in splitting up your codebase into crates. Like SURE... You CAN do this in C++, but it's usually just simply not worth the bother, because you gain next to nothing