> 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.