On Wed, Aug 14, 2024, 11:07 AM Lanre <lnearw...@gmail.com> wrote: > > On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel <m...@newclarity.net> wrote: > >> >> On Aug 12, 2024 at 4:13 PM, <Lanre <lnearw...@gmail.com>> wrote: >> You’d have to be seriously naive to believe that “the entire industry is >> actively trying to move AWAY from C/C++.” >> >> >> Well, there is this: >> >> >> https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF >> >> -Mike >> > > The source mentions Python and Swift as "memory-safe languages," both of > which are implemented in C and C++. How does that work if C and C++ aren't > memory-safe? >
This is the wrong analyze and approach. How many issues happen the past years in the core of a language vs the apps using it would be a better data. As another example, go is written in go btw. My argument about using other languages to write extensions or sapi for php is about ease the development and allow more people to do it. FrankenPHP is a very good example. There are others. Mozilla introduced Rust years ago, yet Firefox remains primarily C++, with > only about 3% of the codebase in Rust. By dismissing C and C++, one > overlooks the fact that they are crucial for powering everyday systems such > as elevators, automotive control units (ECUs, ADAS), medical devices, > consumer electronics, industrial automation, and more. > Some of my code running automates on z80 still run. Yet, newer models use mips cpu and C. Similarly cobol is still used, so are some c cgi applications. It IS naive to believe that “the entire industry is actively trying to move > AWAY from C/C++.”. > you are extrapolating for the sake of it. Every industry has a certain latency to move from one tech to another (or non tech). It does not prevent new solutions to grow and be used. also the main topic being how to handle the few cases using c++ dependencies have been elegantly solved already. >
