NSA to Businesses: Please stop using C and C++

[AlTech]

Summary
The US' NSA has issued advice that Businesses should stop using C, C++, and memory unsafe languages.

 

The NSA says C and C++ usage is prone to poor memory management that can be exploited by hackers and other criminals and recommends businesses to instead use memory safe languages such as:

• C#
• Rust
• Go
• Java
• Ruby
• Swift

 

Other experts The Register talked to argue that whilst so called "band aid" solutions can harden memory security with C or C++, they argue that a "band aid" solution is not a full solution.

 

Quotes

Quote

The NSA has released guidance encouraging organizations to shift programming languages from the likes of C and C++ to memory-safe alternatives – namely C#, Rust, Go, Java, Ruby or Swift.

 

"NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations," advised the agency.

 

My thoughts

 Much as I think that Rust is an obvious replacement for C and C++, it is quite lacking in terms of IDEs and tools dedicated to it and its learning curve is too steep IMHO. I think the Rust lang people should address the latter cos that's one of the big barriers to more devs using Rust: learning curve coming from other languages.

 

I think the NSA giving this advise is particularly helpful to business people who may manage or run parts of companies that create software or even software companies; because ultimately the people who decide what programming languages a company uses is mostly the CTO and ocasionally project leads.

 

Sources

 https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/

[DrMacintosh]

10 minutes ago, AluminiumTech said:

Java

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

Nah fr, I am a huge advocate for changing the codebase of products. Applications should be rewritten often. Doing so allows your dev teams to be more familiar with the code, lets your product adopt new technologies, and improves security. Software should not exist unchanged for 20 years simply because it works. 

[leadeater]

56 minutes ago, DrMacintosh said:

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

 

Literally anything but that please

[Vishera]

1 hour ago, AluminiumTech said:

use memory safe languages such as:

• C#

That's my boy!

1 hour ago, DrMacintosh said:

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

Nah fr, I am a huge advocate for changing the codebase of products. Applications should be rewritten often. Doing so allows your dev teams to be more familiar with the code, lets your product adopt new technologies, and improves security. Software should not exist unchanged for 20 years simply because it works. 

Java nukes performance,

Moving a project from Java to C# significantly improved performance for me.

 

That reminds me that Minecraft has a Java edition and a non-Java edition,

Guess which version has better performance?:

 

[starsmine]

#RustIsTheFuture

Get the performance of c++ while being memory safe and not worrying about Jr devs doing their thing, or Sr Devs making a silly stupid dumb mistake that no one will find for 4 years. Where is the downside?

4 hours ago, DrMacintosh said:

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

Nah fr, I am a huge advocate for changing the codebase of products. Applications should be rewritten often. Doing so allows your dev teams to be more familiar with the code, lets your product adopt new technologies, and improves security. Software should not exist unchanged for 20 years simply because it works. 

rewriting software just adds more bugs you never had before and does not necessarily improve security as those new bugs can be nasty zero days. 

[Salv8 (sam)]

all of those languages are terrible choices.
rust isn't stable enough for enterprise use.

ruby is SLOWER then java in some cases.

java may be able to run on any system but the performance penalty isn't worth it for most applications.

swift only runs on linux and apple devices. (also making it useless for enterprise use since many still run windows)

barely anyone cares about go and has the chance of google axing it at anytime (i don't think you want to see it on killedbygoogle.com)

and C# was designed for winforums and can't do more advanced things such as interacting with GPU's, often requiring third party library to get the job done. (and considering a lot of businesses are starting to use A.I more and more, it makes it a terrible choice) (also a lot of these library are longer updated or have abandoned development and almost every one runs on C++ or C, asking the question, why not develop the app itself in C or C++ and reduce the risk of unknown software running on your systems)

the only 'new' programing language i've seen being used by businesses, is python.

and even then it's not that great due to how slow it can be at times.
we're better off just improving how C and C++ manage memory since it would encourage enterprises to just upgrade their software instead of writing new ones (causing them to put it off until it's to late and they get fucked over), which would decrease time spent on keep their systems safe and secure allowing them to figure out more ways to keep it safe and secure (making the executives happy since there's less of a chance of them getting fucked and getting into trouble) and the programmers wouldn't need to learn a new bloody language (allowing them to focus on improving the current software while also decreasing the chance of a massive vulnerability because a senior programmer didn't catch some badly written code)

 

C and C++ aren't great and are damn old, but in the face of competition they still can hold their own despite their age.

[wanderingfool2]

6 hours ago, DrMacintosh said:

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

Nah fr, I am a huge advocate for changing the codebase of products. Applications should be rewritten often. Doing so allows your dev teams to be more familiar with the code, lets your product adopt new technologies, and improves security. Software should not exist unchanged for 20 years simply because it works. 

While i do agree that a code base should be updated as technology changes...I wouldn't say it should be rewritten often...that's just asking for things to slip in that don't belong or having buggy versions of rebuilds.  I wouldn't say that it improves security necessarily either, it just means that you might have more code that has been vetted less (and maybe even a few slipped in dependencies because people are using a package now to lets say write log files)

 

Log4J anyway

 

The general mentality I have, code should be changed to meet new hardware and the newer OS's...but the fundamental code shouldn't be changed if it's working properly as it can be more of a tried and true method (that has been hardened over time).  To express what I mean, there was a place I worked at that had a pretty good backend software, it was "rewritten" to now run with the more modern stuff...so that there would be less need for some specialized hardware etc.  The system itself was so buggy compared to the original (the original was still maintained/updated, like it could run on Windows 10).  By the time I left the US division was still trying to work out all the issues, and there was serious grumblings about moving back to the "legacy" system.
 

[AlTech]

5 hours ago, starsmine said:

#RustIsTheFuture

Get the performance of c++ while being memory safe and not worrying about Jr devs doing their thing, or Sr Devs making a silly stupid dumb mistake that no one will find for 4 years. Where is the downside?

Surely it would get found out just by compiling it? The compiler in Rust is particularly good at finding problems and preventing your code from running until you fix the problems.

5 hours ago, starsmine said:

rewriting software just adds more bugs you never had before and does not necessarily improve security as those new bugs can be nasty zero days. 

 

[AlTech]

5 hours ago, Salv8 (sam) said:

all of those languages are terrible choices.
rust isn't stable enough for enterprise use.

In what sense?

5 hours ago, Salv8 (sam) said:

ruby is SLOWER then java in some cases.

java may be able to run on any system but the performance penalty isn't worth it for most applications.

Well that's why people weigh Java's performance against how easy it is to write and read Java code.

5 hours ago, Salv8 (sam) said:

swift only runs on linux and apple devices. (also making it useless for enterprise use since many still run windows)

Fair.

5 hours ago, Salv8 (sam) said:

barely anyone cares about go and has the chance of google axing it at anytime (i don't think you want to see it on killedbygoogle.com)

Google is invested in Go though. They have no reason to kill it off.

5 hours ago, Salv8 (sam) said:

and C# was designed for winforums and can't do more advanced things such as interacting with GPU's, often requiring third party library to get the job done. (and considering a lot of businesses are starting to use A.I more and more, it makes it a terrible choice)

There are AI libraries for C# and low level ways of interacting with GPUs through bindings to Vulkan, OpenGL, and other libraries.

 

Though, how often do businesses need GPU interaction in their application? I'm tempted to say not that often.

5 hours ago, Salv8 (sam) said:

(also a lot of these library are longer updated or have abandoned development and almost every one runs on C++ or C, asking the question, why not develop the app itself in C or C++ and reduce the risk of unknown software running on your systems)

the only 'new' programing language i've seen being used by businesses, is python.

and even then it's not that great due to how slow it can be at times.
we're better off just improving how C and C++ manage memory since it would encourage enterprises to just upgrade their software instead of writing new ones

I feel like the industry's been there and done that but it's just not enough to fix the problem.

 

Besides, there is only so many improvements you can do to a language prone to these issues.

5 hours ago, Salv8 (sam) said:

(causing them to put it off until it's to late and they get fucked over), which would decrease time spent on keep their systems safe and secure allowing them to figure out more ways to keep it safe and secure (making the executives happy since there's less of a chance of them getting fucked and getting into trouble) and the programmers wouldn't need to learn a new bloody language (allowing them to focus on improving the current software while also decreasing the chance of a massive vulnerability because a senior programmer didn't catch some badly written code)

 

C and C++ aren't great and are damn old, but in the face of competition they still can hold their own despite their age.

 

[leadeater]

4 hours ago, Salv8 (sam) said:

C# was designed for winforums and can't do more advanced things such as interacting with GPU's, often requiring third party library to get the job done. (and considering a lot of businesses are starting to use A.I more and more, it makes it a terrible choice) (also a lot of these library are longer updated or have abandoned development and almost every one runs on C++ or C, asking the question, why not develop the app itself in C or C++ and reduce the risk of unknown software running on your systems)

How does that make it a terrible choice? Tons of projects use 3rd party libraries and other tool chains so I really don't see how this is such a huge negative. Also there are well supported ways to use GPU with C# projects.

 

4 hours ago, Salv8 (sam) said:

the only 'new' programing language i've seen being used by businesses, is python.

and even then it's not that great due to how slow it can be at times.

High performance python is actually possible and quite a lot of researchers use python in HPC applications. While highly versatile I wouldn't say it's a good choice for general application development. Then again a lot of applications are moving over to web driven and delivered with standardized HTTPS API message passing which does make it greatly more applicable.

[Arika]

I know they probably mean well, but i find it extremely amusing that the NSA of all groups is telling people to use different languages because hackers are exploiting C and C++.

 

I like to believe that these are the 2 languages the NSA can't crack and want everyone using something they have infinite back doors available for.

[starsmine]

42 minutes ago, AluminiumTech said:

Surely it would get found out just by compiling it? The compiler in Rust is particularly good at finding problems and preventing your code from running until you fix the problems.

 

no, the compiler will not tell you about the majority of runtime errors, just compilation errors. it may warn about bad ideas, but ask how many devs pay attention to those.

 

  

5 minutes ago, Arika S said:

I know they probably mean well, but i find it extremely amusing that the NSA of all groups is telling people to use different languages because hackers are exploiting C and C++.

 

I like to believe that these are the 2 languages the NSA can't crack and want everyone using something they have infinite back doors available for.

... what?

Like I get your point, NSA and their elliptical curve encryption scandal and all that. but that is not how coding works. you dont "crack" a language. 

[hishnash]

10 hours ago, AluminiumTech said:

I think the Rust lang people should address the latter cos that's one of the big barriers to more devs using Rust: learning curve coming from other languages.

I think that depends a lot on what you are doing. C and C++ are used for so many things, many of witch rust is a poor option. Rust is a great option for some things. 

 

[Dracarris]

11 hours ago, AluminiumTech said:

Java

Go hug a train, dear NSA.

[Kisai]

12 hours ago, AluminiumTech said:

Summary
The US' NSA has issued advice that Businesses should stop using C, C++, and memory unsafe languages.

 

The NSA says C and C++ usage is prone to poor memory management that can be exploited by hackers and other criminals and recommends businesses to instead use memory safe languages such as:

• C#
• Rust
• Go
• Java
• Ruby
• Swift

 

Other experts The Register talked to argue that whilst so called "band aid" solutions can harden memory security with C or C++, they argue that a "band aid" solution is not a full solution.

 

Quotes

 

My thoughts

 Much as I think that Rust is an obvious replacement for C and C++, it is quite lacking in terms of IDEs and tools dedicated to it and its learning curve is too steep IMHO. I think the Rust lang people should address the latter cos that's one of the big barriers to more devs using Rust: learning curve coming from other languages.

 

I think the NSA giving this advise is particularly helpful to business people who may manage or run parts of companies that create software or even software companies; because ultimately the people who decide what programming languages a company uses is mostly the CTO and ocasionally project leads.

 

Sources

 https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/

 

It won't happen. You're not going to see a rewrite of 50 years of software. The best case scenario is...

1. A new operating system is NATIVE, and defacto "memory safe", without that existing, you can have the safest Rust software, but the OS can still be exploited. Does that mean the OS has to be written in Rust too? Not necessarily, but it seems like too much of a stretch to ask Windows, MacOS or Linux to do this.

2. The entire tool chain must be written in the same language. Won't happen. Hell I've seen "tool chains" change three times since the 90's, and each time it just gets worse. Cmake is cool when it works, but it mostly doesn't work consistantly on different platforms, with it generally not working at all on Windows due to the expectation of how things do it on Linux. Mixing and matching cmake with libraries without cmake, pain.

3. "new" projects must be written in "static" Rust (eg not the dependency hell of C DLL/.so files) so that they can be staticly compiled so there's no "runtime patching" going on. You can have the best written software in the world, but it's an effortless hack to add or replace a DLL file. This is how "mods" for unity games presently work, and EVERYTHING in Unity is C#, even the IL2CPP stuff, which can be decoded back to C#.

4. No "IL" or "Interpreted" languages to be used in security or privacy aspected software. Java and C# are not good languages to use if there are legal consequences to the data leaking, because MITM attacks for cross-compiled and interpreted languages are a thing. Write your game in C# but write your netcode, encrpytion and authentication parts in Rust.

 

As you can tell, nobody is going to do this, not this century. The busy body syntax refacterers will enjoy porting 100 year old C and C++ programs to Rust that are still in use then. In the mean time, just don't start new projects in C/C++. If there are no Rust bindings, don't use it, rewrite the library if it has source if you really need it, or do without.

 

11 hours ago, DrMacintosh said:

Oh yeah, I can feel it. Java is gonna make a comeback bois! 

 

Nah fr, I am a huge advocate for changing the codebase of products. Applications should be rewritten often. Doing so allows your dev teams to be more familiar with the code, lets your product adopt new technologies, and improves security. Software should not exist unchanged for 20 years simply because it works. 

20, try 40. When we switched from 16-bit to 32-bit OS's (by which I mean Windows NT and MacOS X, not Windows 95/3.1+win32s) we should have stopped using hand-coded assembly. When we switched to 64-bit software we really should have stopped developing new software in C and C++, but can't because the OS's are still C bindings.

 

There's too much to change, and throwing everything out to start over has never been considered until virtualization came along. At least virtualization gives us an option to try and sandbox things if there was just the will to do so.

 

There are several libraries that everyone uses (eg OpenSSL to name one, also the entire way sockets work on all platforms for another) or descendants of it, that will be unavoidable for the forseeable future and I think it's wishful thinking to expect any software to be rewritten in Rust unless the software is extremely critical for security reasons instead of performance. 

 

The entire reason memory safety problems exist in C and C++ is because people aren't machines and tend to not think about how their code will be used in the future, only how it will be used now.

[Franck]

7 hours ago, Salv8 (sam) said:

C# was designed for winforums

C# was design for winforms and console apps 20 years ago. This has shifted alot.

 

7 hours ago, Salv8 (sam) said:

and can't do more advanced things such as interacting with GPU's

Heard about something called Unity ? Or maybe DirectX, OpenGL or maybe even Vulkan. What about Nvidia Cuda ?

 

7 hours ago, Salv8 (sam) said:

and considering a lot of businesses are starting to use A.I more and more, it makes it a terrible choice

ML.NET is one of the most used AI machine learning tool out there.

[Doobeedoo]

Reading the title I was so C# then? Also screw Java no. Also UE5 doesn't even support C# natively? That reminds me, when will they fix that shader compilation issue nonsense...

[AlTech]

1 hour ago, Kisai said:

 

It won't happen. You're not going to see a rewrite of 50 years of software. The best case scenario is...

1. A new operating system is NATIVE, and defacto "memory safe", without that existing, you can have the safest Rust software, but the OS can still be exploited. Does that mean the OS has to be written in Rust too? Not necessarily, but it seems like too much of a stretch to ask Windows, MacOS or Linux to do this.

Linux is already starting to add Rust code to their kernel.

 

I would hazard a guess that macOS probably has replaced some of their C++ code with Swift code in the past few years.

 

As for Windows, yes it's a bit too late for that but Azure's CTO is a big believer in Rust and also wants to stop using C and C++.

1 hour ago, Kisai said:

2. The entire tool chain must be written in the same language. Won't happen. Hell I've seen "tool chains" change three times since the 90's, and each time it just gets worse. Cmake is cool when it works, but it mostly doesn't work consistantly on different platforms, with it generally not working at all on Windows due to the expectation of how things do it on Linux. Mixing and matching cmake with libraries without cmake, pain.

3. "new" projects must be written in "static" Rust (eg not the dependency hell of C DLL/.so files) so that they can be staticly compiled so there's no "runtime patching" going on. You can have the best written software in the world, but it's an effortless hack to add or replace a DLL file. This is how "mods" for unity games presently work, and EVERYTHING in Unity is C#, even the IL2CPP stuff, which can be decoded back to C#.

4. No "IL" or "Interpreted" languages to be used in security or privacy aspected software. Java and C# are not good languages to use if there are legal consequences to the data leaking, because MITM attacks for cross-compiled and interpreted languages are a thing. Write your game in C# but write your netcode, encrpytion and authentication parts in Rust.

C# .NET is already used in such circumstances. If you don't hardcore data then what's the issue?

1 hour ago, Kisai said:

As you can tell, nobody is going to do this, not this century. The busy body syntax refacterers will enjoy porting 100 year old C and C++ programs to Rust that are still in use then. In the mean time, just don't start new projects in C/C++. If there are no Rust bindings, don't use it, rewrite the library if it has source if you really need it, or do without.

 

20, try 40. When we switched from 16-bit to 32-bit OS's (by which I mean Windows NT and MacOS X, not Windows 95/3.1+win32s) we should have stopped using hand-coded assembly. When we switched to 64-bit software we really should have stopped developing new software in C and C++, but can't because the OS's are still C bindings.

 

There's too much to change, and throwing everything out to start over has never been considered until virtualization came along. At least virtualization gives us an option to try and sandbox things if there was just the will to do so.

 

There are several libraries that everyone uses (eg OpenSSL to name one, also the entire way sockets work on all platforms for another) or descendants of it, that will be unavoidable for the forseeable future and I think it's wishful thinking to expect any software to be rewritten in Rust unless the software is extremely critical for security reasons instead of performance. 

 

The entire reason memory safety problems exist in C and C++ is because people aren't machines and tend to not think about how their code will be used in the future, only how it will be used now.

 

[LAwLz]

Sounds like good advice to me.

Please remember to read the full article (preferably the NSA guidance) to get the full nuance of these news, not just the headline.

 

 

Some things to keep in mind:

1) The guidelines are about safety, not necessarily performance.

 

2) The guidelines isn't telling anyone "rewrite your code!". The guideline basically says "hey, it might be a good idea to consider writing new code in a memory safe language if possible".

 

3) The guidelines clearly states that for security reasons, memory safe languages should be used when possible. Nobody is saying "write your Windows programs in Swift and your iOS app in Go".

 

4) Roughly 70% of the software vulnerabilities in Microsoft and Google software are caused by unsafe memory operations such as buffer overflows. 

 

 

 

  

4 hours ago, leadeater said:

High performance python is actually possible and quite a lot of researchers use python in HPC applications. While highly versatile I wouldn't say it's a good choice for general application development. Then again a lot of applications are moving over to web driven and delivered with standardized HTTPS API message passing which does make it greatly more applicable.

Pretty sure any "high performance python" is C(++) in the backend. 

[tim0901]

2 hours ago, Franck said:

Heard about something called Unity ?

Unity doesn't actually use C# like that. Yes you write your scripts in C#, but Unity has a backend (IL2CPP) that compiles the .NET IL files to C++, which is then compiled again to form the binary. Similarly, none of the back-end engine stuff is written in C# either, it's all C++. As such, Unity games aren't actually running any C# code by the time you ship them.

 

2 hours ago, Franck said:

Or maybe DirectX, OpenGL or maybe even Vulkan. What about Nvidia Cuda ?

Confused what you're even trying to say here.

 

DirectX is written in C/C++.

Vulkan is written in C.

OpenGL's most commonly used version (Mesa3D) is written in C/C++.

CUDA is written in C++.

 

Additionally, none of them officially support C# or have a C# API. Some of them have third party libraries you can use, but those are still just wrapping up the C/C++ API in some syntactic sugar, and from my experience they're generally very poorly maintained. From a cursory glance, I can't find a C# wrapper for CUDA that's been touched in years.

 

If you want to use these libraries in your C# codebase you definitely can, but the easiest way to achieve this - which a lot of people do - is to write all the graphics code in C++ and then create a wrapper interface between it and the rest of your code.

[BachChain]

I remember seeing something recently that Nvidia had started using SPARK a few years ago for stuff that needed formal verification.

[WhitetailAni]

6 hours ago, AluminiumTech said:

Google is invested in Go though. They have no reason to kill it off.

They were invested in Stadia too... and Loon... and Google+...

2 hours ago, AluminiumTech said:

I would hazard a guess that macOS probably has replaced some of their C++ code with Swift code in the past few years.

They're moving away from C++ and UIKit and towards Swift and SwiftUI. The Ventura Settings app is written entirely in SwiftUI.

 

I'm not so sure this is a good thing - it's got quite a few bugs. I sure love it when pressing Cmd+A crashes Settings!

[Franck]

1 hour ago, tim0901 said:

Confused what you're even trying to say here.

 

DirectX is written in C/C++.

Vulkan is written in C.

OpenGL's most commonly used version (Mesa3D) is written in C/C++.

CUDA is written in C++.

The guy said that you cannot interact with GPU using C# which is false. DirectX is done with the .net Direct3D class (including DirectSound and DirectInput for things like xbox controller), OpenGL with OpenTK/SharpGL, Vulkan trough VulcanSharp directly in Mono. Finally Cuda for internal dev we still have Altimesh tool with licensing.

 

It had nothing to do about what language it was made of. And mostly any C# code can now be compile to C++ with native compilation and equal and sometime even be faster than C++ equivalent.

[wanderingfool2]

7 hours ago, leadeater said:

High performance python is actually possible and quite a lot of researchers use python in HPC applications. While highly versatile I wouldn't say it's a good choice for general application development. Then again a lot of applications are moving over to web driven and delivered with standardized HTTPS API message passing which does make it greatly more applicable.

Could be wrong, I only really ever bothered touching a bit of python code, but I think typically when you do that "high performance" stuff in python it is still in things like C/C++.  You can effectively make python methods using C/C++, and that's how some of those things speed up.  The benefit of doing it parts of it in the slower python though is that in general with python you get a whole lot more flexibility (or rather even less skilled people are able to rapidly make changes or tweaks without having to recompile).  The heavyset methods would be written by people who do know C/C++ though.  So you get the best of both worlds that way.

 

11 hours ago, Salv8 (sam) said:

-snip-

I think it's important to realize though what "most" applications are though.  Sure there are a bunch of projects that do require more optimal runtimes...but I'd also argue that many many projects are capable of being run in those lesser languages as the performance penalty isn't great enough to justify the additional development time.  I've seen projects written in Java, VBA, C#, etc.  Languages each have their perks and I would bet that a large amount of projects could use lets say Java and not have any meaningful impact on performance.

 

The reason why you would avoid C/C++ is it's too easy for junior (or even senior) programmers to make a mistake that isn't easy to spot (unless someone goes over all the code and even then it can be overlooked).  Heartbleed being a perfect example of how a senior dev/programmer can make one mistake and leave the world open to attack.

 

C#, again you don't necessarily need access to GPU or AI libraries.  Actually, I think a lot of AI work is being done in python more...either way though in C# you can import standard dll functions to call.  So if you wanted to use something from C/C++ you could actually just import the dll file.

 

Realistically at this stage in the game, unless performance is absolutely necessary there are better options.

[tim0901]

31 minutes ago, Franck said:

The guy said that you cannot interact with GPU using C# which is false. DirectX is done with the .net Direct3D class (including DirectSound and DirectInput for things like xbox controller), OpenGL with OpenTK/SharpGL, Vulkan trough VulcanSharp directly in Mono. Finally Cuda for internal dev we still have Altimesh tool with licensing.

So... with the exception of DirectX, those are all third-party libraries, as I mentioned. And many of the ones you've listed - as I also mentioned - are basically dead and haven't been touched in forever. VulkanSharp hasn't seen any development in over 3 years, meaning it doesn't support Vulkan 1.2 or 1.3, while Altimesh claims to not support anything more modern than CUDA SDK 10.1, which is also over 3 years old at this point. Even SharpGL has only seen a single commit in the last 2 years.

 

I agree it's definitely doable and, in an existing project, these issues are of course perfectly acceptable if the libraries aren't causing issues, so I fully get why you would continue to use them. But if I'm starting a project today - be that something new or a re-write of an existing project - choosing tools like these that haven't been touched in forever, and therefore I know I will get zero support for if I encounter any issues, isn't exactly appealing. Additionally, I'm probably going to want to pick more modern tools such as Vulkan or Dx12, as opposed to the now ancient and basically depreciated OpenGL.

 

31 minutes ago, Franck said:

It had nothing to do about what language it was made of. And mostly any C# code can now be compile to C++ with native compilation and equal and sometime even be faster than C++ equivalent.

Sure, but compiling your C# code to C++ means you aren't, as is the whole point of this thread, actually re-writing your programs in memory-safe languages and avoiding the problems of C/C++. Memory safety bugs etc. can and will still exist, they are just going to be introduced by a third-party, eg Unity, rather than by you. You're not actually solving the issue being discussed, just hiding it under a layer of abstraction.