3 ms·

The amount of iconoclastic knee jerking in this thread is kinda nuts. Equating this rebuttal to an old man yelling at clouds? Saying Cpp never made sense? The

The amount of iconoclastic knee jerking in this thread is kinda nuts. Equating this rebuttal to an old man yelling at clouds? Saying Cpp never made sense? The first step to solving a problem is accepting reality. Cpp has been foundational, like C, to our computing world. If the rich legacy of libraries that underpin our "better" language choices is offensive to us, or if we really believe we are powerless to improve the situation around the most popular programming language(s) then we're not being realistic. This is a huge debate of national importance and it'll shape programming language design for decades, it's important to get this right, and that will take more than just once choice and more than one approach to get right.

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 ago
  I'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 ago
    It’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 ago
    I 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 ago
      Yes, 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 ago
        Should ≠ 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.
deleted 3y ago
[deleted]
froh 3y ago
yes! and a core part of getting this right is the maturity of other features, like generics/templates, duck typing instead of or in addition to inheritance, portable and well defined data memory layout, ease of reuse of existing mature C++ libraries (think numerical Fortran). I consider a language defined module system, straightforward parsing and higher level concurrency (like channels) almost icing on the cake... nobody is served with a forced rush from one idiosyncratic complexity to another. and imnsho the core issue with C++ is _not_ "safety" but complexity, of the language as such. it's just way to easy to write leaky or out of bounds writing code, in C and still in C++. and in that vein I really love carbon and Herb Sutter's Work and get me right, also rust and even good old Ada got a lot right. but please, can we discuss the better, next gen systems language as if it were not religions? but technology choices with ups and downs?

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 ago
I'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 ago
  It’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 ago
  I 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 ago
    Yes, 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 ago
      Should ≠ 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.

deleted 3y ago

[deleted]

froh 3y ago

yes! and a core part of getting this right is the maturity of other features, like generics/templates, duck typing instead of or in addition to inheritance, portable and well defined data memory layout, ease of reuse of existing mature C++ libraries (think numerical Fortran). I consider a language defined module system, straightforward parsing and higher level concurrency (like channels) almost icing on the cake... nobody is served with a forced rush from one idiosyncratic complexity to another. and imnsho the core issue with C++ is _not_ "safety" but complexity, of the language as such. it's just way to easy to write leaky or out of bounds writing code, in C and still in C++. and in that vein I really love carbon and Herb Sutter's Work and get me right, also rust and even good old Ada got a lot right. but please, can we discuss the better, next gen systems language as if it were not religions? but technology choices with ups and downs?