It’s not too hard to imagine in a larger code base, where maybe libfrontend is relatively stable but libbackend has active development. Now if I want to update libbackend (maybe a new feature was added, maybe there’s been a critical bug fix) I shouldn’t have to wait for the libfrontend maintainers to update their dependencies, sort out any breaking changes, and verify there were no regressions to do so.
Prior to go modules this was even worse with third party packages. I’ve had cases where my app has integrations with a few google services like maps, sheets, and text-to-speech. It turns out the libraries for all of these services, understandably, also have certain dependencies in common. If you run in to the unfortunate situation where you need to update one of the google libraries, and that updated library now relies on an updated version of a dependency required by others, you’ll end up needing to update all of the other libraries. Granted it’s usually a good idea to update, but it turns a theoretical 1 hour task (update library to use new feature) in to a headache that might take several days depending on how big the changes were to the other libraries
Prior to go modules this was even worse with third party packages. I’ve had cases where my app has integrations with a few google services like maps, sheets, and text-to-speech. It turns out the libraries for all of these services, understandably, also have certain dependencies in common. If you run in to the unfortunate situation where you need to update one of the google libraries, and that updated library now relies on an updated version of a dependency required by others, you’ll end up needing to update all of the other libraries. Granted it’s usually a good idea to update, but it turns a theoretical 1 hour task (update library to use new feature) in to a headache that might take several days depending on how big the changes were to the other libraries