The first and last points are basically nonsense. The others are valid, more or less.
(1) The Rust Foundation was very carefully engineered to not have any influence on the technical direction of the language. Yes, corporations are backing it, someone needs to pay the bills. Yes, they expect to benefit from it. It's pretty clear how - they want to ensure Rust, which they heavily rely on, is continued to be developed.
(2) The Rust compiler does not contain a trusting trust backdoor. It's possible to bootstrap rustc from zero (the original OCaml compiler) or short-circuit with mrustc. This was done and the binaries were identical (yes, not every version was checked). The GCCRS compiler might not be useless, but it is far from being useful enough that the Rust community should shift resources towards it.
It's been over 10 years since Rust 1.0 was released, and C programmers still see it as a new fad. Yet, the same article mentions, but fails to connect the dots, that even the large slow-moving corporations bankrolling the foundation have already adopted Rust and are leaving C as fast as they can.
It's a typical C mindset that rewriting programs creates new bugs, because it takes years to "battle test" and shake bugs out of a C program. In my experience rewrites in Rust uncover latent bugs of C programs when they finally get checked lifetimes, useful type system, enforced error checking, etc.
That's not how rewrites create new bugs. It's not type or lifetime or error checking bugs, for the most part. It's "sometime in the ten years that this code has existed, someone ran into this weird corner case. This little detail right here fixes it. But the guys doing the rewrite weren't around ten years ago, and they don't know that the corner case even exists, so they don't know which specific details of the existing code they need to preserve." And so the handling for corner cases gets lost.
Doing a new implementation that preserves all of the features of existing code in all scenarios is really hard. The re-implementation team never knows all the scenarios that matter.
Is AI going to fix this? AI won't know all the scenarios and corner cases, either.
1:1 rewrites from C are perfectly doable. You can use C FFI and rewrite function by function, bug for bug, while checking snapshot tests. I've converted a few libraries this way, before AI. I caught C bugs this way, and then was able to further refactor and improve the Rust version. In the end, I'm super happy with the results and I'm never touching autotools or cmake again!
The pool of C software worth rewriting is shrinking. There are the few too-big-to-rewrite projects that will never move, but everything else is either getting rewritten, or has more modern replacements already written directly in Rust.
I can't vouch for LLM-assisted rewrites. The results can be randomly dodgy regardless of what you're writing or rewriting. I suspect we'll get plenty more LLM rewrites anyway, and people will just compensate by sending LLMs hunting for bugs by brute force.
> It’s completely possible that Rust’s compiler contains a backdoor... The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation.
There are many problems with the Rust language. None of the things mentioned here are them, though:
1. The Rust Foundation is a legal entity that owns things like the webhosting for servers and stuff that. Are you going to claim that, e.g., the C++ Foundation makes C++ the purview of nefarious evil corporations simply because all of the C++ members are companies?
2. I've never really seen the "social momentum" the author talks about. And even though I work in the kind of environment where you'd think people would be eager Rust converts... I'm pretty much the only person at work who tries to do anything in Rust.
3. "Rewrite-it-in-Rust" memers are viewed negatively by everyone I know, including the actual Rust developers.
4. There's nothing inherent about GPL versus MIT versus Apache or whatnot for Rust libraries. I think the trend in open source over the past decade or so has been to move away from GPL anyways, and that so many Rust packages are non-GPL is simply because Rust code is mostly newer than the heyday of GPL.
5. No, it's not "completely possible" that Rust's compiler contains a backdoor. If you want to, you can bootstrap the compiler from the ocaml-based compiler (which involves way too many steps). I think the mrustc compiler is also capable of building the current rustc. It's pure FUD.
What can I say, I agree with the article's concerns. I think rewriting everything into a non-GPL License by large corporations can be viewed as a first step to locking down Linux in a manner as Cell Phones are now.
This has one of the hallmark indicators of bad analysis: it leaves the reader to complete the author’s thoughts, assuming that we’ll reach the same bleak and conspiratorial conclusions as them.
Cases in point:
- The Rust Foundation has corporate sponsors. Have they, in fact, acted in a manner that should undermine our trust in Rust, the language?
- The Rust compiler could contain a backdoor. Does it, in fact, and what are the reasons we would have to believe that?
The 'woah, slow down' also just feels kinda... late? Rust is pretty mature by now, it's not really some new unproven thing that needs a bunch of work to be useful.
Sure, but that's the case for a lot of languages. ANSI X3.159-1989 (aka C89) shows that just about everyone involved was a representative for some big org, almost all commercial or military.
But if the foundation seems like it's mismanaging Rust, the community should feel free to fork it. The trademark isn't super important at the end of the day, it's the community. And the community is very well represented in the Rust Foundation by design AFAICT.
> There is a certain “social momentum” when it comes to the spread of Rust...
People like it, and it excites/inspires them to use it. And it's more than just memory safety. I commonly use it in deeply embedded cases where I'm doing silly stuff like 'unsafe fn main()'. The memory safety isn't the main draw for me. It's mostly the algebraic types, and the abstraction mechanism that's less interested in hiding data/code relationships than c++ is. The borrow checker is just a cherry on top.
That being said, I wouldn't confuse people's excitement for requirements on others. New code should have to make a case for itself on its own merits.
> One of the Rust community’s main passtimes, a meme at this point, is rewriting existing projects into Rust....
I would strongly encourage more rewriting projects.
What I would discourage is them being widely deployed. I do think Canonical jumped the gun a bit on their Rust adoption with sudo-rs and uutils.
> I believe this culture of rewriting existing projects benefits corporations (again).
This is hardly a Rust thing, and I think more on the ebb and flow of the era with new coders not understanding the purpose of the GPL and thinking that MIT/BSD licenses must mean more free rather than the rather nuanced discussions that can be in favor of either. We are starting to see push back on this though thankfully.
I am curious what the state of this looks like in a couple years given the recent bout of borderline forcible open source rewrites via coding agents.
> It’s completely possible that Rust’s compiler contains a backdoor.
This is practically a non issue; there are people who bootstrap Rust from source.
I would also throw out there that we'll probably see agents sifting through binaries before too long. They'll just be looking for exploitable bugs like the current explosion in LLM found security issues.
This is not quite true: the Foundation handles things like receiving and distributing some payments, helping conferences, employing people for operations (crates.io), and ownership of the trademark. But Rust the language and toolchain is managed by the people doing the work https://rust-lang.org/governance/
> It’s completely possible that Rust’s compiler contains a backdoor. And nobody would know. Now this last point is highly speculative and conspiratorial,
Yes.
> but I’m not the only one concerned about it.4 The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation.
> 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,5
The linked to blogpost is about a fuck up that a subset of people in the project, who were responsible for RustConf, caused. The ones with leadership position stepped down from them out of their own volition. The Foundation in particular had absolutely nothing to do with the whole fiasco.
> I find it hard to trust it at all.
> 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 project6—an alternative compiler which would alleviate the concerns for the possible presence of a backdoor. Currently, it’s in an early phase of development.
Who is the OP talking to? Slow what down? Because there are people working on https://github.com/Rust-GCC/gccrs. I don't work on it, because I do what I do on my spare time and I find it more rewarding to improve the user experience of rustc itself, instead of implementing the same logic for the third time in a language I don't particularly enjoy. Others are equally disinclined to work on a C++ frontend implementation. The project certainly spends its time focused on improving the language. It is also hard to tell people in the Rust Project what to do: it is open source, it is a showupocracy. The people working on it are already at their limit on what responsibilities they can take on.
If the target audience of the blogpost is "the community", I also think it misses the mark. The "X rewritten in Rust" announcements I would see before LLMs would be the projects' own maintainers desiring to use Rust, and not external sources imposing it on others. There have been over enthusiastic people (and trolls) bothering projects in issue trackers and mailing lists, but I've never seen a level of volume commensurate to the meme's fame. (Nowadays I see vibe-coded projects done in Rust, but those are also not imposing their codebase on other existing projects beyond sucking up the air out of the room and making it annoying to read news aggregators due to high volume and low quality).
> 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.
That's quite a view you have of people like myself and my colleagues. I have significant disagreements on how some facts and opinions are framed in the blogpost, but closing with stating that I and my colleagues in the project are ill intentioned and/or don't think for ourselves absolutely ensures that I won't be listening to anything else you have to say in the matter.
Back when Twitter was a thing I'd spend time searching for "negative Rust sentiment" because it was an excellent way of finding unpublished feature requests and real issues that needed to be addressed, after sieving through the less than productive way those real problems were presented with. This latter emotional labor was also the reason that it caused a round of burn out, until I realized that if something is A Problem, more than one person will ultimately hit it. Which means that if there are two people raising the same point, you don't need to waste your time engaging with the one being an asshole, and instead spend your time engaging with the one that will be productive.
On the 'possible backdoor' issue, this excellent and thorough post buries the lede a bit, I think.
What I get when I follow the link is that mrustc is a cleanroom Rust compiler which is only intended to build the official Rust compiler.
So: it provides a way to build a Rust compiler from source, which can then be used to bootstrap itself.
No need for extensive error reporting --- it's ok to assume correct code, and fail messily if not. In fact, the simpler the better, for audit of the alternative implementation.
If one suspects that C/C++ has been also been infected with "Thompson's Trusting Trust" *with respect to the Rust compiler*, then try it using Python, or Perl. Maybe even COBOL. Maybe even Forth (but first you have to bootstrap a suitable Forth, keep us posted...[1]).
If after all that you still think the 'reflexive build chain' is compromised, then either you're truly paranoid, or we are all doomed :-)
[1] I really like Forth (aside from traditional use-cases, it makes a great souped-up calculator DSL), but I don't think it's the tool for this job unless you really do want a 'start from bare metal' proof. If you do, then it could be a way to get there faster than raw assembly.
The first and last points are basically nonsense. The others are valid, more or less.
(1) The Rust Foundation was very carefully engineered to not have any influence on the technical direction of the language. Yes, corporations are backing it, someone needs to pay the bills. Yes, they expect to benefit from it. It's pretty clear how - they want to ensure Rust, which they heavily rely on, is continued to be developed.
(2) The Rust compiler does not contain a trusting trust backdoor. It's possible to bootstrap rustc from zero (the original OCaml compiler) or short-circuit with mrustc. This was done and the binaries were identical (yes, not every version was checked). The GCCRS compiler might not be useless, but it is far from being useful enough that the Rust community should shift resources towards it.
As for the 'rewrite it in Rust' thing...
Depends on what you are rewriting from.
C, you have memory issues, but battle-tested code.
COBOL, you have to hire retiree consultants for $BIG.
Or, twenty years from now, hire psychics for $BIG to communicate with them.
I wonder if some of the RIOR is about worry over C being the next generation's COBOL?
It's been over 10 years since Rust 1.0 was released, and C programmers still see it as a new fad. Yet, the same article mentions, but fails to connect the dots, that even the large slow-moving corporations bankrolling the foundation have already adopted Rust and are leaving C as fast as they can.
It's a typical C mindset that rewriting programs creates new bugs, because it takes years to "battle test" and shake bugs out of a C program. In my experience rewrites in Rust uncover latent bugs of C programs when they finally get checked lifetimes, useful type system, enforced error checking, etc.
That's not how rewrites create new bugs. It's not type or lifetime or error checking bugs, for the most part. It's "sometime in the ten years that this code has existed, someone ran into this weird corner case. This little detail right here fixes it. But the guys doing the rewrite weren't around ten years ago, and they don't know that the corner case even exists, so they don't know which specific details of the existing code they need to preserve." And so the handling for corner cases gets lost.
Doing a new implementation that preserves all of the features of existing code in all scenarios is really hard. The re-implementation team never knows all the scenarios that matter.
Is AI going to fix this? AI won't know all the scenarios and corner cases, either.
1:1 rewrites from C are perfectly doable. You can use C FFI and rewrite function by function, bug for bug, while checking snapshot tests. I've converted a few libraries this way, before AI. I caught C bugs this way, and then was able to further refactor and improve the Rust version. In the end, I'm super happy with the results and I'm never touching autotools or cmake again!
The pool of C software worth rewriting is shrinking. There are the few too-big-to-rewrite projects that will never move, but everything else is either getting rewritten, or has more modern replacements already written directly in Rust.
I can't vouch for LLM-assisted rewrites. The results can be randomly dodgy regardless of what you're writing or rewriting. I suspect we'll get plenty more LLM rewrites anyway, and people will just compensate by sending LLMs hunting for bugs by brute force.
> It’s completely possible that Rust’s compiler contains a backdoor... The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation.
this is interesting but idk if i get it. couldn't you compile it with a different rust implementation like https://github.com/thepowersgang/mrustc
Indeed, and there are multiple projects which provide ways for you to run a full source bootstrap of not just rust but the entire C and C++ toolchain:
https://guix.gnu.org/manual/1.5.0/en/html_node/Full_002dSour...
https://stagex.tools/
(I think nixOS also has some work in this area, but I'm not sure how complete it is)
I was expecting real problems, like the lack of async Drop.
There are many problems with the Rust language. None of the things mentioned here are them, though:
1. The Rust Foundation is a legal entity that owns things like the webhosting for servers and stuff that. Are you going to claim that, e.g., the C++ Foundation makes C++ the purview of nefarious evil corporations simply because all of the C++ members are companies?
2. I've never really seen the "social momentum" the author talks about. And even though I work in the kind of environment where you'd think people would be eager Rust converts... I'm pretty much the only person at work who tries to do anything in Rust.
3. "Rewrite-it-in-Rust" memers are viewed negatively by everyone I know, including the actual Rust developers.
4. There's nothing inherent about GPL versus MIT versus Apache or whatnot for Rust libraries. I think the trend in open source over the past decade or so has been to move away from GPL anyways, and that so many Rust packages are non-GPL is simply because Rust code is mostly newer than the heyday of GPL.
5. No, it's not "completely possible" that Rust's compiler contains a backdoor. If you want to, you can bootstrap the compiler from the ocaml-based compiler (which involves way too many steps). I think the mrustc compiler is also capable of building the current rustc. It's pure FUD.
What can I say, I agree with the article's concerns. I think rewriting everything into a non-GPL License by large corporations can be viewed as a first step to locking down Linux in a manner as Cell Phones are now.
This has one of the hallmark indicators of bad analysis: it leaves the reader to complete the author’s thoughts, assuming that we’ll reach the same bleak and conspiratorial conclusions as them.
Cases in point:
- The Rust Foundation has corporate sponsors. Have they, in fact, acted in a manner that should undermine our trust in Rust, the language?
- The Rust compiler could contain a backdoor. Does it, in fact, and what are the reasons we would have to believe that?
The 'woah, slow down' also just feels kinda... late? Rust is pretty mature by now, it's not really some new unproven thing that needs a bunch of work to be useful.
> Rust is managed by the Rust Foundation...
Sure, but that's the case for a lot of languages. ANSI X3.159-1989 (aka C89) shows that just about everyone involved was a representative for some big org, almost all commercial or military.
But if the foundation seems like it's mismanaging Rust, the community should feel free to fork it. The trademark isn't super important at the end of the day, it's the community. And the community is very well represented in the Rust Foundation by design AFAICT.
> There is a certain “social momentum” when it comes to the spread of Rust...
People like it, and it excites/inspires them to use it. And it's more than just memory safety. I commonly use it in deeply embedded cases where I'm doing silly stuff like 'unsafe fn main()'. The memory safety isn't the main draw for me. It's mostly the algebraic types, and the abstraction mechanism that's less interested in hiding data/code relationships than c++ is. The borrow checker is just a cherry on top.
That being said, I wouldn't confuse people's excitement for requirements on others. New code should have to make a case for itself on its own merits.
> One of the Rust community’s main passtimes, a meme at this point, is rewriting existing projects into Rust....
I would strongly encourage more rewriting projects.
What I would discourage is them being widely deployed. I do think Canonical jumped the gun a bit on their Rust adoption with sudo-rs and uutils.
> I believe this culture of rewriting existing projects benefits corporations (again).
This is hardly a Rust thing, and I think more on the ebb and flow of the era with new coders not understanding the purpose of the GPL and thinking that MIT/BSD licenses must mean more free rather than the rather nuanced discussions that can be in favor of either. We are starting to see push back on this though thankfully.
I am curious what the state of this looks like in a couple years given the recent bout of borderline forcible open source rewrites via coding agents.
> It’s completely possible that Rust’s compiler contains a backdoor.
This is practically a non issue; there are people who bootstrap Rust from source.
I would also throw out there that we'll probably see agents sifting through binaries before too long. They'll just be looking for exploitable bugs like the current explosion in LLM found security issues.
I would like to see other compilers though.
> Rust is managed by the Rust Foundation
This is not quite true: the Foundation handles things like receiving and distributing some payments, helping conferences, employing people for operations (crates.io), and ownership of the trademark. But Rust the language and toolchain is managed by the people doing the work https://rust-lang.org/governance/
> It’s completely possible that Rust’s compiler contains a backdoor. And nobody would know. Now this last point is highly speculative and conspiratorial,
Yes.
> but I’m not the only one concerned about it.4 The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation.
Or using https://github.com/thepowersgang/mrustc. And it is not released by the Foundation.
> 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,5
The linked to blogpost is about a fuck up that a subset of people in the project, who were responsible for RustConf, caused. The ones with leadership position stepped down from them out of their own volition. The Foundation in particular had absolutely nothing to do with the whole fiasco.
> I find it hard to trust it at all.
> 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 project6—an alternative compiler which would alleviate the concerns for the possible presence of a backdoor. Currently, it’s in an early phase of development.
Who is the OP talking to? Slow what down? Because there are people working on https://github.com/Rust-GCC/gccrs. I don't work on it, because I do what I do on my spare time and I find it more rewarding to improve the user experience of rustc itself, instead of implementing the same logic for the third time in a language I don't particularly enjoy. Others are equally disinclined to work on a C++ frontend implementation. The project certainly spends its time focused on improving the language. It is also hard to tell people in the Rust Project what to do: it is open source, it is a showupocracy. The people working on it are already at their limit on what responsibilities they can take on.
If the target audience of the blogpost is "the community", I also think it misses the mark. The "X rewritten in Rust" announcements I would see before LLMs would be the projects' own maintainers desiring to use Rust, and not external sources imposing it on others. There have been over enthusiastic people (and trolls) bothering projects in issue trackers and mailing lists, but I've never seen a level of volume commensurate to the meme's fame. (Nowadays I see vibe-coded projects done in Rust, but those are also not imposing their codebase on other existing projects beyond sucking up the air out of the room and making it annoying to read news aggregators due to high volume and low quality).
> 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.
That's quite a view you have of people like myself and my colleagues. I have significant disagreements on how some facts and opinions are framed in the blogpost, but closing with stating that I and my colleagues in the project are ill intentioned and/or don't think for ourselves absolutely ensures that I won't be listening to anything else you have to say in the matter.
Back when Twitter was a thing I'd spend time searching for "negative Rust sentiment" because it was an excellent way of finding unpublished feature requests and real issues that needed to be addressed, after sieving through the less than productive way those real problems were presented with. This latter emotional labor was also the reason that it caused a round of burn out, until I realized that if something is A Problem, more than one person will ultimately hit it. Which means that if there are two people raising the same point, you don't need to waste your time engaging with the one being an asshole, and instead spend your time engaging with the one that will be productive.
On the 'possible backdoor' issue, this excellent and thorough post buries the lede a bit, I think.
What I get when I follow the link is that mrustc is a cleanroom Rust compiler which is only intended to build the official Rust compiler.
So: it provides a way to build a Rust compiler from source, which can then be used to bootstrap itself.
No need for extensive error reporting --- it's ok to assume correct code, and fail messily if not. In fact, the simpler the better, for audit of the alternative implementation.
If one suspects that C/C++ has been also been infected with "Thompson's Trusting Trust" *with respect to the Rust compiler*, then try it using Python, or Perl. Maybe even COBOL. Maybe even Forth (but first you have to bootstrap a suitable Forth, keep us posted...[1]).
If after all that you still think the 'reflexive build chain' is compromised, then either you're truly paranoid, or we are all doomed :-)
[1] I really like Forth (aside from traditional use-cases, it makes a great souped-up calculator DSL), but I don't think it's the tool for this job unless you really do want a 'start from bare metal' proof. If you do, then it could be a way to get there faster than raw assembly.