[SOLAR_FIELDS]

You don't even have to talk about hypotheticals when it comes to this "vendor everything instead" philosophy. This is basically how the C world works, a lot of which is driven by a general allergy to dependencies by embedded developers - partially out of necessity (space and overhead are MUCH more important constraints in embedded land) - but also partially out of cargo culting.

I guess the opinion I'll share here is that I don't hear too many people arguing that the way embedded developers manage C libraries is at the forefront of how we should be handling and distributing code.

[pton_xd]

Many industries, like AAA game development, work this way.

There's a good reason for it -- code quality and performance is important. Understanding what your code actually does and how it does it, is important.

And as a result, AAA game software is able to push the boundaries of consumer compute performance. Micro-library-built software is generally just bloated crap that barely works. But it is fast to churn out, so there's that.

[SOLAR_FIELDS]

Fair points. But for every bad library there are 10 rock solid ones that are going to do a better job handling edge cases and being performant than you can for almost no additional effort.

Really what this comes down to is the pickiness of package repo maintainers and general skill level of engineers within the ecosystem. This kind of crap and cruft discussed in the article happens in ecosystems where the barrier to entry is tiny. You don’t really hear about left-pad like fiascos in Java land or Rust land. Not saying all devs are great that use these technologies, but in Rust case you really don’t contribute packages without jumping over some serious learning curve hoops and in Java land the canonical repository (Maven Central) is difficult enough to contribute to that it also staves off fly-by-night contributors