MSc Eng, CMSE | Turning your team into Automation Specialists, Integrating IT/OT, and Enabling smarter data management
There's a lot of noise lately about "memory unsafe languages" - especially directed at C and C++. Let's be clear: C/C++ are not unsafe — they are just unforgiving. When used with discipline, understanding, and proper tooling, they remain extremely capable of building performant, stable, and safe systems - as they have done for decades! The real issue isn’t the language itself but where the burden of correctness lies. In C/C++, you are responsible for correctness and safety. This isn’t a flaw — it’s a tradeoff. A conscious design choice that gives power and precision at the cost of guardrails. Let’s stop blaming languages and start valuing engineering discipline. #MISRA #CProgramming #Cpp #SystemsProgramming #SoftwareEngineering
These languages are called "memory unsafe" because they're designed to offer (by default) memory unsafe primitives. This does not limit itself to pointer arithmetics, but includes all UBs. Not sure what issue you have with that classification.
Hmm.. If we call it "memory access without correctness check assistance" will it reflect the situation? Most vulnerabilities are due to memory safety issues (buffer/stack overflows etc).
Loved what you said, "unforgiving". The world of software/firmware development is filled with an ego that blames the creator or creation to seek for something new or easy (read Python developers vs Java vs C vs C++). So with an easy language and language that does things on its own, the preferential treatment riding the incapability in the name of productivity supersedes the talent a programmer has who can actually extract the best out of the so called "bad language" (read C/C++ for some).
When this topic comes up, I always think of the quote: "With great power, comes great responsibility."
Anything can be unsafe if you operate it wrong enough. 😅
Love this take, Emanuel
I agree, It is discipline, right knowledge and experience needed.
This is not a "discipline", it's 100% pure mental overhead. Overall, any "tradeoff" which boils down to "don't forget to ..." is a mental overhead.
MSc Eng, CMSE | Turning your team into Automation Specialists, Integrating IT/OT, and Enabling smarter data management
2wIf you’re curious about where this “memory safety” conversation is headed at the policy level, have a look at CISA’s Product Security Bad Practices (Jan 2025) list. One of the top concerns? Continued use of memory-unsafe languages without adequate mitigations. It’s a clear signal that while C/C++ remain powerful tools, the industry is being urged to take a more structured approach to safety. Worth a read. https://www.cisa.gov/resources-tools/resources/product-security-bad-practices