Elizafox's Ramblings

I wanna vent a bit about dependencies and their hidden cost.

We all know the usual Dependency Hell problems, but there is a much more subtle problem, one I've run into time and time again.

Abandonware

Oftentimes, you run into a library (call it a crate, package, egg, gem, you could call it a poopsock for all I care), and it turns out to be abandoned and hasn't been updated in years. Worse, it may have bugs that you can't work out. So you're stuck forking it, or just copying the code and maintaining it locally in a sort of de facto fork. Yuck.

Variable quality

The biggest problem I've found, however, is variable quality. Oftentimes you think you've found this great library, that meets all your needs... and then you discover it has a terrible interface, or terrible documentation, or is riddled with bugs, or is designed for a completely different application domain.

Gah.

This is literally the worst. It's super annoying too, when the library implements functionality you really don't want to waste too much time implementing yourself, or handles a lot of boilerplate, or what have you.

The case for “batteries included”

I appreciate Python's approach (that they're seemingly abandoning gradually) of “batteries included.”

Stuff included in the standard library usually has many, many eyes on it. It gets audited frequently. It gets reviewed more often. And it's guaranteed not to break, it will work essentially “forever” or until it's deprecated (which you will get plenty of warning about).

Even if nobody is “touching” the code, code doesn't magically stop working when you're not looking at it. As long as bugs get fixed, and it does what it needs to do, it doesn't matter.

If wishes were fishes

I wish Rust's standard library was less minimalist for this reason. But I guess I can dream.

— Elizabeth Ashford (Elizafox) Fedi (elsewhere): @Elizafox@social.treehouse.systems Tip jar: PayPal || CashApp || LiberaPay