What Julia has that Rust desperately needs
By José Díaz • 2 minutes read •
Table of Contents
The situation
The crate ffmpeg-next is a fork of the original and abandoned ffmpeg crate. Now, we have new forks like ffmpeg-the-third and rffmpeg that are more up-to-date. At the same time, ffmpeg-next is now trying to revive. So, which ffmpeg repo should I look at now? Sorry if reading that made you dizzy, but that’s how bad the situation is.
speculoos is a fork of the unmaintained spectral.
The great ort is a fork of onnxruntime-rs.
yaml-rust and yaml-rust2.
serde-yaml and serde-yaml-bw.
It is normal for people to drop open-source software; I’m not saying they should keep working forever. But it’s sad that one person gets to gatekeep everyone else and say, “This is abandoned, I’ll keep the crate name so now you have to make a worse one or be creative.”
Anyway, so. What if all the disorganized effort was centralized and focused?
How Julia solved this problem
The Julia community faced the exact same problem in the past. The solution is quite simple: let’s move the packages into self-organized GitHub organizations.
- Packages for biology? You have BioJulia
- Packages for data? You have JuliaData
- Packages for TidyVerse-inspired packages? You have TidierOrg
By doing this:
- The repos won’t become inaccessible forever
- You have other members (maybe) supporting your work
- We get less noise (fewer forks) and more productivity
- We get a wonderful sense of community
I think governance problems can emerge if people can’t respect each other but the gains are worth considering. This is a HUGE positive for Julia, and I think Rust needs this too.
FAQ
Q: This is not just a Rust problem btw, every programming language has this.
A: They should fix it too. Just talking about what I see.