6 ms·

While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. The gaslighting from certain vocal proponents of

by titzer 3y ago

While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. The gaslighting from certain vocal proponents of C++ has been a major stumbling block for the industry as a whole to move on to using memory safe languages in critical software layers. It was never a good idea to use a performance-oriented language for software that should have had its highest priority as security, and it will be remembered in the long tail of history in the same way that asbestos is: a hazardous material that took us a long time to rid ourselves of.

mkoubaa 3y ago
This take is not helpful imo
- EricE 3y ago
  Truth is often uncomfortable.
  - AnimalMuppet 3y ago
    Perhaps. But not everything uncomfortable is truth. You sound like you're using the uncomfortableness as evidence of the truthfulness. Logical inference doesn't work like that.
ndesaulniers 3y ago
I think JF's recent CppNow talk was excellent in this regard. Particularly his wording: dereliction of duty https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_ https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_
Barrin92 3y ago
not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat is one of the companies that also has a strange C addiction for almost anything. There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.
- loo 3y ago
  Red Hat should switch to Zig.
  - gabereiser 3y ago
    But Red Hat and Rust just Roll off the tongue
    - dmux 3y ago
      Or Red Hat and Red Lang [0] [0] https://www.red-lang.org/ https://www.red-lang.org/
- gabereiser 3y ago
  Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...` When they totally could be doing `go get sources.redhat.com...`
  - klooney 3y ago
    Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).
    - a1o 3y ago
      I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.
SkyMarshal 3y ago
As long as the Rust community doesn’t fuck up Rust, it looks like that transition, and more importantly the broad recognition of its necessity and feasibility, is well underway.
andyjohnson0 3y ago
C was my first love as an adult programmer. I still enjoy its economy and expressiveness, even though I've written no production code in it for over a decade. So it saddens me, but I agree: it's time to retire C and C++, and put some serious work into migrating security/safety critical codebases to more robust languages.
deleted 3y ago
[deleted]
diego_sandoval 3y ago
> we need to move on from it Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust). I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.
- guitarbill 3y ago
  What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.
  - jandrewrogers 3y ago
    Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.
    - musicale 3y ago
      > No one wants to increase data center sizes by 4x (or more) to run the same workload 1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.
  - BaculumMeumEst 3y ago
    Some performance critical software cannot afford garbage collection.
    - pasc1878 3y ago
      Which is why Apple put GC in Objective C and then removed to and Swift does reference counting. To keep iPhone apps responsive, they saw problems with apps using GC.
zozbot234 3y ago
> While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. This has largely happened already. Java is in fact a memory safe language which has replaced a whole lot of C++ code since the late 1990s. It's only in a few highly performance-oriented areas where the debate ("should we be replacing C++ with a memory safe language?") is still undecided.
- nneonneo 3y ago
  Java may be memory safe, but errors in highly expressive functionality like Java serialization and expression parsers have been responsible for some of the most impactful vulnerabilities in recent memory. CVE-2017-5638 was famously exploited to gain access to Equifax's network and cause a massive data breach. Log4Shell is continuing to cause problems in all kinds of networks due to the extremely widespread use of the Log4j library. Java is definitely an upgrade over C/C++, but there are definitely still security risks.
  - pjmlp 3y ago
    When we eliminate 70% of CVE, it doesn't mean the remaining 30% shouldn't be taken care of.
  - nmilo 3y ago
    So then memory safety isn't the end-all be-all for security anyways. What do you suggest we use instead?
    - gilcot 3y ago
      Ada?
      - irundebian 3y ago
        Ada/SPARK
    - a1o 3y ago
      Coq
BaculumMeumEst 3y ago
There's too much friction for Rust to be the solution, unless there are drastic changes in the near future. None of Vulkan, Metal, GTK, Qt, Cocoa, Android, iOS, or Wayland have official Rust support, and maintaining the boundary is a non-trivial task. My gut feeling is that a different language with less friction will gain more traction.
- IshKebab 3y ago
  "None of <list of enormous ancient systems> have official support for <new language>"
  - BaculumMeumEst 3y ago
    I think that is a reductive dismissal of a real problem. Rust is intended as a C++ replacement, but interfacing to existing C and C++ code can be very messy, it’s not just simple language bindings. What I’m suggesting is that the work needs to be spread out or it’s not likely to happen.
    - IshKebab 3y ago
      C is fairly effortless, but I agree C++ could be better. But hardly any languages integrate with C++ very well. Have you ever used SWIG? (Shudder...) I do agree it would be nice if it could. The cxx crate is ok but we could do a lot more. Maybe something like SWIG but based on LLVM so it actually works properly.

by titzer 3y ago

mkoubaa 3y ago

This take is not helpful imo

EricE 3y ago
Truth is often uncomfortable.
- AnimalMuppet 3y ago
  Perhaps. But not everything uncomfortable is truth. You sound like you're using the uncomfortableness as evidence of the truthfulness. Logical inference doesn't work like that.

ndesaulniers 3y ago

I think JF's recent CppNow talk was excellent in this regard. Particularly his wording: dereliction of duty https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_ https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_

Barrin92 3y ago

not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat is one of the companies that also has a strange C addiction for almost anything. There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.

loo 3y ago
Red Hat should switch to Zig.
- gabereiser 3y ago
  But Red Hat and Rust just Roll off the tongue
  - dmux 3y ago
    Or Red Hat and Red Lang [0] [0] https://www.red-lang.org/ https://www.red-lang.org/
gabereiser 3y ago
Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...` When they totally could be doing `go get sources.redhat.com...`
- klooney 3y ago
  Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).
  - a1o 3y ago
    I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.

SkyMarshal 3y ago

As long as the Rust community doesn’t fuck up Rust, it looks like that transition, and more importantly the broad recognition of its necessity and feasibility, is well underway.

andyjohnson0 3y ago

C was my first love as an adult programmer. I still enjoy its economy and expressiveness, even though I've written no production code in it for over a decade. So it saddens me, but I agree: it's time to retire C and C++, and put some serious work into migrating security/safety critical codebases to more robust languages.

deleted 3y ago

[deleted]

diego_sandoval 3y ago

> we need to move on from it Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust). I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.

guitarbill 3y ago
What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.
- jandrewrogers 3y ago
  Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.
  - musicale 3y ago
    > No one wants to increase data center sizes by 4x (or more) to run the same workload 1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.
- BaculumMeumEst 3y ago
  Some performance critical software cannot afford garbage collection.
  - pasc1878 3y ago
    Which is why Apple put GC in Objective C and then removed to and Swift does reference counting. To keep iPhone apps responsive, they saw problems with apps using GC.

zozbot234 3y ago

> While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. This has largely happened already. Java is in fact a memory safe language which has replaced a whole lot of C++ code since the late 1990s. It's only in a few highly performance-oriented areas where the debate ("should we be replacing C++ with a memory safe language?") is still undecided.

nneonneo 3y ago
Java may be memory safe, but errors in highly expressive functionality like Java serialization and expression parsers have been responsible for some of the most impactful vulnerabilities in recent memory. CVE-2017-5638 was famously exploited to gain access to Equifax's network and cause a massive data breach. Log4Shell is continuing to cause problems in all kinds of networks due to the extremely widespread use of the Log4j library. Java is definitely an upgrade over C/C++, but there are definitely still security risks.
- pjmlp 3y ago
  When we eliminate 70% of CVE, it doesn't mean the remaining 30% shouldn't be taken care of.
- nmilo 3y ago
  So then memory safety isn't the end-all be-all for security anyways. What do you suggest we use instead?
  - gilcot 3y ago
    Ada?
    - irundebian 3y ago
      Ada/SPARK
  - a1o 3y ago
    Coq

BaculumMeumEst 3y ago

There's too much friction for Rust to be the solution, unless there are drastic changes in the near future. None of Vulkan, Metal, GTK, Qt, Cocoa, Android, iOS, or Wayland have official Rust support, and maintaining the boundary is a non-trivial task. My gut feeling is that a different language with less friction will gain more traction.

IshKebab 3y ago
"None of <list of enormous ancient systems> have official support for <new language>"
- BaculumMeumEst 3y ago
  I think that is a reductive dismissal of a real problem. Rust is intended as a C++ replacement, but interfacing to existing C and C++ code can be very messy, it’s not just simple language bindings. What I’m suggesting is that the work needs to be spread out or it’s not likely to happen.
  - IshKebab 3y ago
    C is fairly effortless, but I agree C++ could be better. But hardly any languages integrate with C++ very well. Have you ever used SWIG? (Shudder...) I do agree it would be nice if it could. The cxx crate is ok but we could do a lot more. Maybe something like SWIG but based on LLVM so it actually works properly.