Why so many dependencies?

📅 2025-05-10  · ✍️ Bas v.d. Wiel  ·  🏷 design

The main reason why I picked Rust to write DOSContainer is because I wanted to learn it. The second reason is the fact that Rust has a large ecosystem of code that is easy to pick up and use. Some years ago I started coding in C++ and while libraries are indeed nothing new, managing them was like getting your teeth pulled by a toddler with a claw hammer. Rust has cargo, and I’m using a lot of it in DOSContainer!

A little sidestep, because I just love how cargo is named and it has to do with some little-known islands in the ocean east off Australia and New-Zealand. That story unfortunately isn’t a happy one, but it is very fitting.

The indigenous people who inhabited these remote islands encountered Western colonists in the 19th century. These encounters exposed the people of the islands to modern Western goods (the ‘cargo’). Prophet-like figures on the islands started foretelling all kinds of imminent cataclysms and coming utopia, bringing an abundance of food and goods. These figures would attribute the creation of this wealth (the cargo) to ancestral spirits. In order to bring about this utopian state, followers would often be encouraged to imitate the actions of colonists and military personnel, like flag-raising, marching and/or drilling.

The term ‘cargo cult’ came to refer to cultures that would go through rituals of imitation for the purpose of receiving Western goods that they themselves are unable to produce. It’s deeply unfortunate that these people were repeatedly deceived by opportunistic Westerners and the Japanese during WWII, but the phenomenon itself did give software engineers a phrase to use: cargo cult development.

Cargo cult software development centers around the use of third-party code without the ability or desire to understand it fully if at all. You just pull it in and use it. That’s what the cargo tool in the Rust ecosystem allows us to do. You pull in crates of third-party code that fix some sort of immediate problem for you, and you don’t need to understand what’s going on in order to use it.

Why is cargo good?

DOSContainer is a hobby project. I’m primarily interested in fixing my immediate concern, which is the creation of DOS-compatible disk images. There’s a large pile of secondary concerns around this though. Things like parsing ZIP-files, parsing TOML-files, downloading stuff from the internet over HTTP and FTP, handling command line parameters etc. All of these concerns have already been solved, and I’m very grateful that I can just pull in crates that I can use. It allows me to move fast and get to the nitty-gritty of my tool in record time.

When is cargo bad?

At the time of this writing DOSContainer is pulling in around 270 different crates through its extensive dependency graph. That’s 270 pieces of third-party code that I didn’t need to write and that I don’t need to maintain myself. DOSContainer is standing on the shoulders of giants here, but there’s always a dark side involved.

Because I’m just raking in third-party code that I’m not reading, I don’t know if it’s any good at all. I just depend on the reputation of a crate and hope for the best, which is fine for a simple hobby project like mine. Individually I’m in absolutely no position to audit a crate like serde or clap, but this also means I can’t vouch for the integrity of DOSContainer in this regard. If any of my 270+ dependencies has a major security issue or gets hit by a supply chain attack, DOSContainer itself will also be affected.

For a simple hobby project that’s fine, although it’s good for any user to be at least aware of this situation. Big projects like the Linux kernel or the FreeBSD operating system should be very careful in how they treat the cargo ecosystem. I’d err on the side of caution and simply forbid the use of any crates from outside the project’s own scope.