> Rust is good but not great. Being able to import two major versions of a lib into the same compilation unit (am I understanding this correctly?) is a huge win.

The one time I needed that I found a pretty good workaround: you make two crates `helper_old` and `helper_new` and have each depend on different versions of that crate. Then I just pub re-exported the crate it depends on.

That way your other crate can now depend on two different versions of that dependency.

This is also the standard approach in the java world, where it's known as "shading."

"Shading" obviosuly comes from the plugin of the same name. But I think of shading to refer more to the practice of repacking classes into a single jar, than the renaming of package name spaces. As far as the standard approach to supporting muliple library versions in one application, i think OSGI is probably the closest thing to a workable solution.

Genius! I trust you will be authoring a new book "RustOps in Practice".

seems like that’d be a decent compiler trick

> import two major versions of a lib into the same compilation unit

When does this situation come up? What is a compilation unit in this case?

It comes up with apis that deal with data storage or IPC concerns.

You might need a handler for both versions if you have customers that use the old api and ones that use the new one. Or different departments of the same customer.

Or if you dodge that bullet but have to write a custom migration tool to get data from the old version and cook it to go into the new one. Half of the code is read only and the other write mostly but they still have to coexist if you do anything more complex than a backup/restore script.

If the newer version of some library has some breaking changes, you can migrate bit by bit instead of doing it all in one go.

If this is the only motivation for multiple dependency versions in the same compilation unit (crate), I'm not convinced. You would be trading off the simplicity of each crate specifying a range of acceptable dependency versions for specifying `N` ranges of acceptable dependencies, and requiring one of each. Much better to enforce one version per compilation unit, and if you want to get complex with your dependencies, then break your project into multiple compilation units.

That needs language support too, some languages simply do not support it. I believe this includes Go due to how linking works. This could be fixed but it would be hard, maybe a 2.0 thing and it does make package management harder. And in a monorepo it doesnt happen so Google doesnt care.