On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).
On the other hand, when weighing one’s feelings against the common good, I guess it’s not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?
Did you forget /s. Banning C/C++ is a terrible idea.
You don’t have to ban C or C++; you just have to prove your programs are memory safe. It’s been decades since I’ve coded in C, but surely Valgrind and ilk are now capable of providing reasonable proof of memory safety. You might have to turn up all the dials and set all-warnings-are-errors, but I’d be surprised if C tooling wasn’t available to provide sufficient proof for a given statically-linked program.
Be prepared to be surprised then. If such tooling was available, why isn’t it being used by the projects for whom it matters? Yes, there is tooling available, but all the big parties using them are admitting it’s not good enough for them. Those tools help, but they do fail in the “sufficient proof” department.
For some follow-up reading:
They all share the same basic facts: C and C++ are inherently memory unsafe. If any of them could’ve “just prove[n] your programs are memory safe”, I think they would have.
Oh, my dear, sweet, summer child. Welcome to capitalism, and the rule of “good enough.” Static code analysis tools cost money, and take time to run. I’ve yet to work at a company that didn’t have a documented process for entirely bypassing QA in urgent situations; although, when I contracted with the USFS, they were much more reluctant to cut corners - that was under a Democrat president; when Republicans took charge, they cut a lot of things, including software quality controls.
But - as I said - I haven’t touched C in decades, so I can’t refute your claim that such tools don’t exist.
Reasonable, sure. But it’s still far from being perfectly “memory safe”
Nothing, and certainly not Rust, is “perfectly” memory safe. You get closer with Haskell. At some point, you define what “good enough” is, and it’s up to languages to provide tooling to either meet those standards (and be approved), or don’t.
Granted, it’d be far harder for, say, Ruby to meet those proofs than a language like Rust, but the critical point is to have a defined standard of “good enough” for languages to work towards.
I agree, which is one of the reasons I think it’s a stupid rule to put in place, to begin with. A lot of so called memory safe languages are just built on top of C anyways (which is not considered memory safe).
True, but that’s what the industry is already aiming for anyways. But vulnerabilities won’t stop happening any time soon
I want Lemmy to have reactions, so I do’t have to clutter the thread just to say: 🤝