I think memory-safety is a great idea. I’m mainly a C programmer and I’m all too familiar with the “fun” of debugging memory issues. But I believe the pace at which Rust is being adopted is dangerous for the following reasons:

• Rust is managed by the Rust Foundation, which defines itself as “an independent nonprofit committed to a safe, secure, and sustainable future powered by the Rust programming language”. Alright, fair enough. But who owns the Rust Foundation? Its founding members are Amazon, Google, Huawei, Microsoft, and Mozilla. The semantics of “independent” and “nonprofit” could be argued about all day, but I think it would be naïve to trust that five corporations would come together to manage a project without believing it would benefit them. Rust is a language that has been growing from corporate interests since the very beginning. A dedicated seat on the Rust Foundation Board of Directors can be bought for the modest sum of $325,000 per year.¹

• There is a certain “social momentum” when it comes to the spread of Rust. A fear of missing out, a culture of replacing the old with the new, a trend. I believe Rust should be viewed the same way as any new technology—with suspicion. Rust has somehow become a label to identify yourself with. A person can be viewed as smart, progressive, safe, if they simply use Rust. It has managed to convince some programmers that it’s the only way forward, and that it should be used without thinking critically of its trade-offs.²

• One of the Rust community’s main passtimes, a meme at this point, is rewriting existing projects into Rust. This is in my opinion the absolute worst way to go about increasing security. It might just be the best way to increase Rust usage without receiving any of its benefits. Rust is not magic, it can’t fix logical errors. Rust programmers still need to be good programmers. But even a good programmer’s power is limited when tasked with reinventing the wheel. When did it become desirable to replace reliable, tested software that has been subjected to years and years of bugfixes, with completely new rewrites? How is that safe at all?

• I believe this culture of rewriting existing projects benefits corporations (again). Currently, projects that usually end up being rewritten in Rust start off with a GPL license, and end up with MIT. Corporations can’t use code from GPL projects without contributing to them in some way. Once the license is changed to MIT through a Rust rewrite, the project is free to be used for whatever purpose benefits corporations the most. An example would be creating locked-down Linux distributions, creating digital prisons. In short, Rust programmers are doing free labor for corporations that fear repercussions from embedding GPL code into their products. They are being tricked into creating a prison for themselves under the guise of “safety” and “efficiency”. I owe this argument to Jody Bruchon.³

• It’s completely possible that Rust’s compiler contains a backdoor. And nobody would know. Now this last point is highly speculative and conspiratorial, but I’m not the only one concerned about it.⁴ The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation. In theory, this binary release could contain a backdoor that gets copied into any subsequent version of the compiler during bootstrapping. It’s also entirely possible that the binary release is completely fine. That’s the problem. Since there exists only a single fully-functional, usable implementation of the Rust compiler, the Rust Foundation must be trusted. Considering its history, owners, and track record of issues with mismanagement,⁵ I find it hard to trust it at all.

Now all this babbling about problems would be incomplete without outlining a solution. My suggestion is: slow down. First, the community should focus on improving the Rust language itself instead of trying to “improve” other projects by rewriting them. I propose using that energy to help the GCC Front-End for Rust project⁶—an alternative compiler which would alleviate the concerns for the possible presence of a backdoor. Currently, it’s in an early phase of development.

It could be said that none of these issues are problems with the Rust language itself—the “language” being the actual formal grammar that defines how Rust is written. This is true. Personally, I believe Rust is undeniably an improvement over C++ on a purely technical basis. But technology relies on people. And the people associated with Rust often don’t seem to have the best intentions in mind, or are just following a trend without thinking for themselves.

To learn about issues with Rust’s language design, I suggest reading Nimfsoft’s blog post.⁷