4 ms·
> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. A
by klodolph 3y ago
> The first step to solving a problem is accepting reality.
Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage.
Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasonable, because C++ isn’t safe enough for most needs. Second, we invest a lot of energy into making C++ safer, with better tools, safer libraries, changes to compilers, static analysis, run-time instrumentation, etc. It won’t close the gap—C++ is still unsafe and will be for the foreseeable future—but it will make a big difference to the people who, for whatever reasons, still use C++ despite its safety problems.
The C++ FAQ has a better picture here:
https://isocpp.org/wiki/faq/big-picture https://isocpp.org/wiki/faq/big-picture
> In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.
There are a lot of good reasons to use C++. C++ is also unsafe. Both are true.
We don’t need to write long apologia explaining why C++ is actually safe, and you shouldn’t be looking at legacy code, or you need to hire better programmers, or you’re using the wrong tools or wrong practices or something like that. Ultimately, those arguments don’t withstand scrutiny.
- User3456335 3y agoI've yet to see a valid scenario where C++ is superior to Rust, Python and Go. Use Python. If you need concurrency, then use Go. If you need even more performance, use Rust (using unsafe Rust only for the parts that need it). For the highest performance stuff, maybe consider C for critical parts only. C++ is not safe. It's a minefield of things that compile but are memory management mistakes. And then you're like "Look, I have a map of the minefield. If we just make sure we don't step on any mines, we are completely fine."
- Scubabear68 3y agoIt’s not just the lack of safety. It is all the insane gaggle of features, from the multipage errors from template errors to “diamond inheritance” to experts yelling at each other over temporary lifetimes. The language has always been a dumpster fire. The best thing I can say about it is that is spurred development of many other languages to get away from it.
- klodolph 3y agoI can think of a few scenarios for C++ off-hand. Most of them involve integrating with libraries or frameworks that are written in C++, running on platforms that have good C++ toolchains, or working with verification systems that can process certain C++ or C subsets.
- User3456335 3y agoYes, but all of these are essentially all because the existing code is already based on C(++). We should be able to move to Rust sooner than people think.
- klodolph 3y agoShould ≠ will. We still have Fortran and Cobol. It’s easy to imagine that Rust will replace C++ Real Soon Now, because you just have to imagine that all of the legacy code disappears, and Rust gets all the tooling support that C++ has.
- lostmsu 3y agoDon't use Python. You will produce unmaintainable code that will have to be thrown away in 5 years because it is impossible to refactor.
- User3456335 3y agoInteresting. Are you sure it's the language and not the programming style? There doesn't seem to be a reason to prevent you from writing maintainable Python code.