I don't usually use this space to share thoughs that don't concern my projects, but this time I'll make an exception. I'd like to share some thoughts on the recent trend of wanting to use the RUST language everywhere and the initiative by the United States government to push for mandatory use of the RUST language. The big slogan behind is memory safety. That's because the RUST language uses several build-time strategies to avoid erroneous access to previously unallocated or deallocated memory areas. I've used the RUST language in the past to program some very complex things, including a multithreaded paced transport protocol, so I know exactly what I'm talking about. The idea of ​​making RUST a mandatory language is nothing short of insane and impractical, and I'll explain why, providing some valid arguments.

First of all, the rust language was born because the incompetence of some programmers in following the right practices for making safe the use of memory in those software programmed in languages like C++ that does not provide you any guarantee of safety. Its existence therefore arises from a sense of "defeat" towards programmers in general, as if to throw in the towel: it's not really your thing. And if you think that static and dynamic code analysis may help you, take another step back: it's not really your thing. Memory safety comes first. It doesn't matter how inconvenient it is to program, how long the development time will be, how many restrictions and how much use you can make of your time (and artificial intelligences!) to program things that in C++ you could have done in 5 minutes: the important thing is memory safety.

Well, let's start then from this first preconception: memory safety. Those who program in RUST do so with the expectation that any memory safety problem will be solved forever, including hacker attacks that exploit software flaws, segfaults that crash processes, and so on. Nothing could be further from the truth. When you develop software, there is always an unsafe point where you have to access memory, in fact even in Rust there are the so-called unsafe sessions that allow unsafe use of memory. Of course these sessions concern only a small percentage of the software (typically ABIs, the use of hardware resources and external libraries) but it's enough to know that only a single dangerous access to memory can compromise the functioning of the entire software. Therefore, even in Rust it's very possible to have unsafe use of memory with segfaults and crashes, even of the entire operating system. Programming in RUST will make programmers so ignorant about the sensitive issues of memory safety that in these few sessions will be even more risky than now.

Unless you program really badly, there is already a similar pattern in C++: the software is structured with typically memory-safe operations and few classes where memory usage is critical, precisely to avoid that an error can be repeated in multiple places. If you program well in C++, if you make use of asserts, if you create logs, if you make attention and respect the basic principles of memory safety, if you use software for static and dynamic analysis, you will have the equivalent of RUST language with safe and unsafe sessions.

But even pretending that the rust language solves any kind of memory safety problem, you can still have: panics (the equivalent of asserts), glitches, wrong behaviors, performance issues, process aborts, death locks and memory leaks (oh yeah, you can have them). The language is so complex, composed, constructed and built on external crates, that finding an error can be really difficult and time expensive. The syntax may be cryptic and tends to cram what would normally be many lines of code (especially iterative loops) into a single line, making the code non-human readable in some points. Build times can be 10 to 100 times longer, so isolating suspect code, building, and re-running the test can be really frustrating, especially considering how difficult it is to get the compiler to let you pass a build or do some free experimentation with the code. It is such a difficult language to program that there are entire crates to do the most basic things, like managing strings, threads, data structures, containers and moving data around in memory. You need to include all these dependencies and the size of the code, as well as the project folder, increases dramatically. It is not uncommon for the folder to take up a few gigabytes, and for builds to be tens of megabytes, for things that in C++ would have taken up a few hundred kilobytes.

Given all these problems and considering that most applications, operating systems and drivers are programmed in C/C++, saying that this language will be made mandatory is really crazy and impractical. I alone programmed an entire framework in C++ made of 300000 lines of code with intensive data processing that never crashes in weeks of execution: with texture mind desktop I streamed one uninterrupted remote display session for 1 week without a single crash or a memory leak, and I'm just a single person. It's very rare to me to see a segfault in one of my software, and when it happens it's very easy to debug and fix, I don't see why large companies like Google, Amazon and Microsoft would need a language like rust even to make it run the "hello world" without a crash.

The truth is that anything that arises from the obligations of a superpower is never anything good. And all this for what? To provide security for lazy multi-billion dollar companies that want to hire mediocre, underpaid software developers who never programmed in their lives and graduated the day before. A money business disguised as a national security issue. The more we are forced to obey, the more we will lose our individual freedoms. I really hope that rust everywhere will never be a reality. Thanks for reading.