On Fri Jan 31 2014 at 3:03:54 PM, Tony Arcieri <[email protected]> wrote:
I am 100% clear that, from a technical perspective, Rust has the ability to support multiple different versions of the same library simultaneously. However: 1) Is this a good idea? Of course it's a good idea. There's a need for that today in C++, Python and other languages. Without this feature you end up in the clash of "there's no single version that satisfies all of my deps" and you're sad and unhappy. And waste time and money. With Rust, the symbols won't conflict so there's no downside. 2) Is this compatible with the idea of toposort-style dependency resolution? I honestly can't even say I understand what exactly you mean by "toposort-style dependency resolution", but I can't help but feel that the answer to your question is *"Why do we care?".* Implementing an algorithm that fulfills the design I and others have proposed is trivial. Can anyone point to a real-world example of a dependency resolver which can produce solutions which may-or-may-not contain multiple versions of the same library? What's the point? I don't know of any language other than Rust that doesn't bork when you link/load/eval multiple versions of a library in the same binary/process/interpreter. So no other language even *could *have implemented this without hacks like adding the library version to its name/namespace/whatever. Let's not limit what we can build for Rust by constraining ourselves to what others have built for languages that don't have Rust's capabilities. -- Tony Arcieri
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
