Considerations about the US plan of making RUST mandatory – All that glitters is not gold

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 about 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 makes use of several build-time strategies to avoid erroneous access to previously unallocated or deallocated memory areas. I've used RUST 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 with languages (like C++) that don't provide any guarantee of safety. Its existence arises from a sense of "defeat" towards free computer programming 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 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 software flaws, hacker attacks, segfaults, crashes 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  external 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 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. Programming in RUST will make programmers so ignorant about the sensitive issues of memory safety that it 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 multiple times. 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 stuff, like managing strings, threads, data structures, containers and moving data. 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 project 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++, making RUST 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 TextureMind 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 the "hello world" run without a crash.

The truth is that the restrictions imposed by world super-powers are never 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 this "rust everywhere" thing will never be a reality. Thanks for reading.

Leave a Reply