They’d be better off just compiling the package manager with Fil-C
No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain
They’d be better off just compiling the package manager with Fil-C
No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain
Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius.
It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT more into the community space.
At this time, most of the work on APT is spent by me staying awake late, or during weekends and my 2 week Christmas break, the second largest chunk is the work I do during working hours but that's less cool and exciting stuff :D
Adding Rust into APT is one aspect; the other, possibly even more pressing need is rewriting all the APT documentation.
Currently the APT manual pages are split into apt-get and apt-cache and so on, with a summary in apt(8) - we should split them across apt install(8), apt upgrade (8) and so on. At the same time, DocBook XML is not very attractive to contributors and switching to reStructuredText with Sphinx hopefully attracts more people to contribute to it.
> since it only supports amd64
Sorry to double-reply, but this is actually a super important point in favor of Fil-C.
If you adopted Fil-C for apt, then you could adopt it optionally - only on ports that had a Fil-C compiler. Your apt code would work just as well in Fil-C as in Yolo-C. It's not hard to do that. I think about half the software I "ported" to Fil-C worked out of the box, and in those cases where I had to make changes, they're the sort of changes you could upstream and maintain the software for both Fil-C and Yolo-C.
So, with Fil-C, there would be no need to ruffle feathers by telling port maintainers to support a new toolchain!
As far as I understand, Fil-C changes the ABI of the system, therefore it requires a new architecture in Debian terminology, e.g. amd64fil. And then you'd need to use multi-arch to pull in amd64fil binaries where that works.
We'll have to see how this plays out but it's not super plug and play.
Exactly something like that, yeah.
Some notes about that here: https://cr.yp.to/2025/fil-c.html
> since it only supports amd64 at this time and is maintained by a single genius.
That's easily fixable.
> It also doesn't help you to attract new contributors.
I don't understand this point.
> > since it only supports amd64 at this time and is maintained by a single genius. > That's easily fixable.
as easily as fixing Rust to work on the remaining 4 architectures?
> > It also doesn't help you to attract new contributors. > I don't understand this point.
C++ doesn't attract a lot of developers, Rust attracts many more. I want more community, particularly _young_ community. I don't wanna work on this alone all the time :D
> as easily as fixing Rust to work on the remaining 4 architectures?
Easier, because you won't have to port Fil-C to all of the architectures in order to use it on amd64.
> C++ doesn't attract a lot of developers, Rust attracts many more.
C is #2 on TIOBE.
C++ is #3 on TIOBE.
Rust is #16 on TIOBE.
So I don't know what you're talking about
Rust is #16 on TIOBE, down from #13.
GitHub also just published Octoverse 2025 and Rust still hasn't cracked the top 10: https://github.blog/news-insights/octoverse/octoverse-a-new-...
Meanwhile, C++ is steadfast and even C is on the edges.
Looking at these lists, Go is an interesting option. It's rising in popularity and there is also a young community interested in it. It also integrates much better with existing C projects. Are there requirements for manual memory management? Would porting to Go instead of Rust have noticeable impacts on performance? Thinking about it now, Go seems like a more prudent option than Rust that achieves all of the publicly stated goals.
he just said from experience that switching projects to rust got them many new contributors.
i guess it's cool for c(++) to have nice tiobe rankings but if they're not contributing how is that relevant?
He got a lot of contributors because those contributors wanted to participate in a rewrite. I.e. the opportunity to "move fast and break things". Not exactly the kind of contributions you should be looking for in a package manager that so many of us rely on.
If he was asking for C/C++ contributors, he'd be asking for help maintaining a mature project. That's less fun. It mature, grown-up work for serious people. Those serious people probably already have serious jobs. So, fewer people will show up.
Focus on a language that isn't a moving target, sir.
And this argument about "young" contributors is the same nonsense that came from your senior management. But you're independent.
Aren't the experienced engineers supposed to be leading the next generation? If you really want to get the young folks on board, drop Ubuntu and call it Gyatt. Instead of LTS, call it Rizz. Just think of all the young who will want to work on Skibidi 26.04!
Rust attracts hype and hype artists. Ask me how I know. Do you want drive-by people or do you want long-term community members? There are many young folk interested in learning C and looking for adequate mentorship along with a project to work on. Wouldn't that be a better use of energy? Have you even put out any outreach to attract others to these projects where you say you're alone?
You are making a mistake and falling on the sword for your bosses at the same time. Tough days are here but maybe hold on for better employment than this.
I agree with this. Fil-C is really impressive and Rust can panic, too (if panics/aborts are a concern).