Türkçe
The report on Product Security Bad Practices warns software companies and developers about developing new products (critical infrastructure and national softwares) with memory-unsafe programming language like C, C++ etc.
In a nutshell, America's Cyber Defense Agency says that you shouldn't use anymore memory-unsafe programming languages because of some critic potantial attacks.
In 2021, a staggering 67% of zero-day vulnerabilities were tied to memory safety problems.
This rate actually says a lot of thing to us.
What are alternatives ?
There are several alternatives on memory-safe programming language. The most important point is that a new alternative can replace an older one. Because memory-unsafe programming languages like C and C++ have almost raw strong on every field of computer science. Also, some companies because of warns about to performance, ecosystem and community support. So they postpone their transform to memory-safe languages.
Safe Memory Alternatives:
- Rust
- Golang
- Ruby
- Kotlin
- Dlang
All of these have automatic garbage collector and preventing memory leak. This makes them very robust.
Especially, Rust is very strict about memory safe and it provides a low-level access on hardware and offer to developer high performance.
What other developer think about that
Some developers look a positive to new programming language which is a memory-safe. However, others don't want to switch because they spend their years to be master in C or C++ and they built a lot of softwares which are robust and don't contain any memory leak. This means a really experienced programmers or engineers can develop safe softwares with "memory-unsafe programming languages".
Additionally, Linus Tolvard started an attemp to change some kernel modules of linux from C to Rust.
Blocks in this way
In tech market, not only developer also companies concern about switching to new safe-memory programming languages. These are reasons why companies don't switch or they do it slowly:
- Stabilization Problems
- Not enough community support
- Small circle thirth-party libraries
- Developers familiar with new technologies demand higher fees
- Few developers who know memory-safe languages
In summary, if a developer is not yet proficient in writing memory-safe code using memory-unsafe languages, they should consider learning memory-safe programming languages to enhance security and avoid common vulnerabilities.