I was struck by how fast the tech industry is adopting Rust in order to solve the memory safety problems in C/C++, so I sat down and graphed it, according to various sources. Given that 70% of serious security bugs are caused my memory safety problems in C/C++, this change has interesting security implications. I predict that Rust will overtake C and C++ by 2030 based on current trends.
I see the technical advantages of Rust as a programming language, but I’m not excited about the fact that so many Rust projects are using permissive licenses (Apache, MIT) rather than Copyleft licenses (GPL, LGPL, AGPL). With the Redox OS or Theseus OS kernel, the Brush or Ion shell, the uutils tools and a Wayland server, you basically get an entire operating system that can be privatized because there are no Copyleft components.
You have some dodgy line breaks where C++ is written as
C+
+
(three occurrences that I noticed). That won’t compile.
One thing that I wondered about is machine translation of programming language (and I’m not talking here about some flaky LLM AI-trained guess, I’m talking about a hand-coded rigorous translation from one programming language to another in the same sense that a compiler purports to translate source code ultimately to a binary while preserving the semantics of the program).
The reason to do that would be, for example, to accelerate the move to safe languages.
This might not be politically viable in some open source projects but let’s say some private company signs The Pledge and is looking to move its internal / proprietary code base quickly.
Your article discusses lots of languages so there are many potential pairs of source and destination language but some pairings are presumably more viable than others.
I haven’t tried to write a Rust program much at all yet, instead got pulled into extensive C++ the last few years, but when I was trying to compile Axolotl or Flare or whatever in the hopes of accessing Signal messenger on Librem 5, it seemed to be the case that building and compiling a program took a very, very long time and automatically used GitHub as a source of dependencies rather than first asking the user if they trust GitHub prior to compiling.
I can see translating C/C++ code into a semantic intermediate representation (SemIR), that can then be translated into a memory safe language. This is similar to how Google’s Carbon project is handling interoperability between C++, Rust and Carbon code, before compiling all the languages for LLVM.
The big problem, however, is that you can’t just translate C/C++ code into Rust code, because that code will have variables that violate the Rust ownership model, so you have to manually refactor the code to be able to compile in Rust.
In Rust, the cargo build system automatically downloads the code of dependencies from the crates.io repository before compiling. crates.io is controlled by the Rust Foundation, which in theory is independent, but Microsoft, AWS, Google, Huawei, Meta and ARM are platinum members of the Rust Foundation. In other words, the Rust Foundation probably won’t do anything that goes against the interests of the tech giants, because its funding depends on them.
Rust might very well rise to the top of the 3GL pack, but it is still just another 3GL. It fails to raise the abstraction level, so it won’t lead to a change in magnitude in quality or productivity. It still fails to address the separation of functional and non-functional concerns, and thus spoils opportunities for large scale reuse (just like all the other 3GLs).
Popularity contests are just fashion, so Rust will probably enjoy it’s 15 years of fame. (Note: fame does not equal usage. Monitor the concentration of programming articles to judge fame.)
The actual point of Rust, as I understand it (disclaimers apply) is that because Rust avoids all the really silly low level coding errors (like use-after-free, failure to check for error return, buffer overflow) it allows Rust programmers to spend their time avoiding or at least fixing higher level logic and other errors. It does not purport to avoid all coding errors so, yes, you can still make brain-dead rookie security errors in Rust.
Hard-coded credentials and some other authentication weaknesses can be avoided in a run-time environment where authentication is removed from the application code altogether and moved into configuration data. It would still be possible to ship hard-coded credentials but at least then any individual site can easily remove those credentials.
So I was wondering, out of all the pairs of languages (with the destination language “safe” and the source language “unsafe”) which ones would be most amenable to rigorous machine translation. That could impact on the overall popularity e.g. by 2030. Because if someone is going to have to (re)visit thousands of lines of long-mature code, that is both cost (effort) and risk.
Rust also just crashes when something in this direction is not implemented as it should, which leads into a fix afterward. For Linux kernel it means that a Rust CVE is probably no real security issue, but just that kind of a crash. Or it just does not compile and is therefor fixed before published. Things I read about, but I am no Rust programmer myself.
But as you said, it is just a number of issues that are not possible. Real CVEs can always happen. But the amount of CVEs should be drastically lower.
First of all, this only makes sense if your source language is C or C++, because the vast majority of memory unsafe code is written in those two languages. You would probably want to translate C to Go for best performance or to C# if doing tricky stuff with pointers. For C++ code, the best option is to translate to C#, but C# only supports single inheritance, so not all classes will translate. There are other problems such as C++ templates don’t always translate to C# generics.
However, if you need the performance of C/C++ plus memory safety, your only real option is to translate to Rust and then spend time manually modifying the code, since Rust uses object composition rather than object inheritance, generics instead of templates, enumerator matching instead of nullable values, single ownership of memory spaces, loop iterators instead of C-style for loops, etc. You could translate to C3 or Odin to avoid some of these problems, they also use object composition, and they still allow memory unsafety, so you have to wonder what is the benefit of switching the language.
The second issue is that it makes no sense to translate from assembly or machine code, because you would lose so much info that the translated code would be horrible to read and a nightmare to try to edit. For example, you probably lose object inheritance, operator overloading, all virtual definitions, etc. in translation. If you want translated code that is legible and maintainable, you need to translate directly from the C/C++ source.
Like I said, there is no 3GL that addresses my concerns.
Like Mythical Man-Month says, there is no silver bullet.
My preferred form of OO development is Shlaer-Mellor domain models (of functional requirements) translated (capturing some of the non-functional requirements) into C. Model translators (that I know of) also exist for Java, C++, SystemC, and Ada.) I haven’t seen one for Rust yet. One could translate direct to object code, but that non-functional requirement handling is already sufficiently handled by the 3GL compilers.
Unfortunately, this type of development lost the popularity contest, and is either doomed to obscurity or reinvention.
