I had the pleasure of going to RustConf 2025 in Seattle this year. During the conference, I met lots of new people, but in particular, I had the pleasure of spending a large portion of the conference hanging out with Jeremy Soller of Redox and System76. Eventually, we got chatting about EFI and bootloaders, and my contributions to PostmarketOS, and my experience booting EFI-based operating systems (Linux) on smartphones using U-Boot. Redox OS is also booted via EFI, and so the nerdsnipe began. Could I run Redox OS on my smartphone the same way I could run PostmarketOS Linux?
Spoilers, yes.
↫ Paul Sajna
The hoops required to get this to work are, unsurprisingly, quite daunting, but it turns out it’s entirely possible to run the ARM build of Redox on a Qualcomm-based smartphone. The big caveat here is that there’s not much you can actually do with it, because among the various missing drivers is the one for touch input, so once you arrive at Redox’ login screen, you can’t go any further.
Still, it’s quite impressive, and highlights both the amazing work done on the PostmarketOS/Linux side, as well as the Redox side.
It’s certainly nice to see Rust making progress with its native implementations. However, its adoption is also creating friction within the larger open-source community — including myself — as it gets pushed into established projects.
Core Utilities
There has been a push to replace perfectly good GNU utilities with “from scratch” implementations in Rust. This has led to some regressions, as recently seen with the performance of coreutils in Ubuntu. While I can opt for other Linux distributions with more mature GNU utilities, with better performance, features, and stability, this trend is part of a larger pattern.
The Git 3.0 Push
Perhaps the most significant one came recently with the news that Git wants to introduce Rust as a hard requirement for version 3.0. To add insult to injury, the new 3.0 format would not be backwards compatible.
So, your repos or clients cannot talk to newer ones. Causing a hard split in the open source community.
This has serious bad news for the broader open-source world, especially for those not on mainstream Linux or FreeBSD on Intel or ARM blessed platforms. ReactOS project for example, or emerging ISAs like RISC-V will be put in a difficult position. They will have to:
a. Divert their limited resources to port and maintain Rust on their platform.
b. Maintain a fork of Git 2.0, risking incompatibility with popular providers like GitHub and cutting themselves off from outside contributions.
c. Attempt to convince Git maintainers that this is a bad idea, though they seem to have set their minds.
It does not have to be this way. They can make a good offering and people can choose to use their Rust platform. But pushing the responsbility to others will cause a well deserved pushback.
Adding links here, as the main comment seems to get blocked:
https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
A very “soft” way of reporting serious performance regressions. I wonder why…
https://www.reddit.com/r/linux/comments/1nm2y05/git_introduce_rust_and_announce_that_it_will/
A good way to convince people to like Rust by forcing them to run a Linux virtual machine just to be able to keep using Git.
sukru,
That’s been part of the debate we’ve been having for a long time. The question is if safe languages can make significant progress in our lifetimes without adoption by existing projects. Some people think the answer is no and that the best path for adoption is to get safe languages into existing projects. While it’s hard for me to call this conclusion wrong because I think it may be right, the result clearly rubs some people the wrong way,
It looks like the C version of cksum supported SIMD whereas the rust version did not. Even though I can tell you’d rather keep using the C version, at least it’s a good sign that these deficiencies were detected and are being addressed.
If that’s really their plan, then I’d agree with you that it’s a stupid one. However I find it a bit unfair to blame rust for this. Wouldn’t you agree the fault lies with git devs? A change in format might be justified, but it’s irresponsible not to provide a migration tool. I don’t like it, but we’ve seen a lot of instances of FOSS projects being managed haphazardly. For better or worse, a lot of project managers are rather careless about the needs of downstream users. Someone might release a migration tool if enough people complain.
As far as I can tell, the Git 3.0 transition to a new incompatible format is this: https://git-scm.com/docs/hash-function-transition
In a nutshell: sha-1 is being deprecated everywhere because of now being insecure, but git depends heavily on sha-1. Because of this, git-scm.com is adding support for a new git format that uses sha-256 instead of sha-1.
The new format is orthogonal to the rust tooling, but IMHO having git 3.0 also require rust complicates the transition a lot, as some currently supported platforms are not yet supported by rust. To my eyes, it would be a lot more reasonable to introduce the rust tooling after there is a stable git with the new format, so that all the currently supported platforms have access to the new git format.
Antartica_,
That is true. They don’t need to have Rust as a hard requirement for Git 3.0, and the could have kept many other platforms supported.
It seems like Rust comes in for an optional new feature called reftable. However their timing, and also making a hard requirement is what makes this an unpalatable change.
Antartica_,
This must be because rust uses LLVM instead of GNU. I don’t know how many people actually need to run git on archaic niche architectures, but maybe GNU should make their own rust compiler? I wouldn’t be against this. It could promote some healthy compiler competition for rust.
In fact, the gcc people are making their own rust compiler (gccrs), but it is far from finished.
Alternatively, there is the https://github.com/thepowersgang/mrustc rust transpiler , written in C++, that is capable to translate some versions of the rustc compiler codebase into C so it compiles with gcc. But it is not a generic tool and only supports the bare minimum to fulfill its intended use: bootstrapping rust.
The problem for alternative implementations is that rust is a very fast moving target, and crates follows the current version, so implementing an old version of rust is not that useful.
Antartica_,
Yes, it is nice to have alternative implementations. But as you said it is a moving target. Like any other young language, Rust is still practically at the “the compiler is the language definition” stage.
Alfman,
That is only part of the puzzle.
In order for the Rust language become really available for a platform (OS + ISA), it needs to have several things.
1 – Compiler frontend
2 – Compiler backend (LLVM)
3 – Linker and other tools
4- Runtime library
To their credit Rust provides a no_std minimal runtime library that has no operating system dependencies (like I/O). They also have a generic memory allocator. (Takes care of 4)
LLVM is widely available, but as you mentioned not as much as GCC would be. It is still a good goal to have wider LLVM adoption, so this takes care of 2.
That leaves us with (1) and (3). The compiler frontend, which is entirely written in Rust, and the accompanying tools.
Unfortunately the frontend cannot be platform agnostic. So, even though we have (4), in practice it means little. (Or rather the parse is agnostic, but being required to have a binary disqualifies that. And we still need that linker, which would need platform libraries)
In other words, platforms like Haiku on amd64, or Linux on RISV-C could at best benefit from cross compilation on another platform where llvm and Rust toolkit available. But would have “iffy” support of natively hosting their own build system.
This is a big loss, as the maturity of a platform can be measured by its ability to self host, and self build.
This puts a lot of strain on alternate OS developers who area already stretched thin. They need to make sure gccrs works on their platform, and use that to bootstrap rustc and continue to maintain this… for having a basic tool like Git, which was completely supported and did not need additional manpower.
Alfman,
To be clear, I’m not blaming Rust as a language. I find it as a positive change (at least pushes C++ to do better).
What I blame is
1. At least some portion of the Rust “community”
2. The Git maintainers who don’t act like seasoned software engineers.
The reason that potion of the Rust community, or rather zealots is doing this is they want to push responsibility. to others. How do I know? I takes one to know one. I used to be a Linux zealot, the kind of person who would go with friends to the computer lab, erase all Windows machines and install Linux. It would then require everyone else to learn and adopt, since the change was already there.
Anyway, the way they are going with this is detrimental, especially the tone.
Again,
You catch more flies with honey than vinegar.
sukru,
Well, it kind of sounds like there are two rather different complaints:
1) Git issues
I don’t think we should be blaming rust’s community for the git issues. The vast majority of the rust community have no hand in what’s going on with git.
2) The idea of broadly migrating existing projects to rust, which has nothing to do with git (other than being an example for it).
Naturally this one’s more a matter of opinion, but I do understand that there’s resistance to the notion of replacing old mature software with rust. People have different attachments to old software and/or don’t see a point in rewriting the software. While different people will assign a different priority to this, the problem is that the industry perpetually faces the consequences of unsafe coding practices invented half a century ago. Right now I’m working on a legacy C/C++ code base that was written in the 90s. They’re still finding bugs that are complicated to reproduce, much less find them, related to unsafe memory behaviors. It’s been proven time and time and time and time (etc) again that human checks are far less thorough than computers at upholding rules for memory safety in the face of software complexity. Generational dynamics are evident here, legacy software devs typically don’t want change, but new generations are naturally more open to it. It’s been half a century of unsafe languages and counting, a good run. but C keeps the software industry in the never-solve-robustness rut problem, and furthermore it’s impeding evolution.
As power plays go, I don’t actually know that rust is actually going to win this one. The grass roots movement is strong, but a new C language built by C programmers for C programmers to address the safety issues and bringing it up to par with rust could quickly overtake rust. The big fish usually wins unless they’re so against adapting that they cause themselves to become disfavored by the market.
If it wasn’t clear before, yes I agree with you, but the blame for this deserves to be directed at git devs, it has nothing to do with rust.
Alfman,
Yes, I blame the two groups separately:
1 – git maintainers for not being accommodating for alternate OS platforms
2 – a portion, the “zealous” part of Rust community, that wants to inject their tools everywhere.
I have the mindset of “right tool for the right job” now.
Yes, I used to push things in the past. That is why I understand that. (In addition to “pirate” Linux installs, I would do hours long language wars as well. They all seem childish looking back all these years later)
sukru,
I guess I could be guilty of it too, but I’ve felt that system software needed to evolve beyond C long before rust came along. Of course some will disagree and consider replacing C to be zealous, but on the other hand others would say these changes are long overdue. We need to dig out of the unsafe language rut system programmers are in. I’d like to see alternatives other than rust, but rust seems to be making the most progress and I think momentum in the direction of safe languages is a positive.