4 ms·

Loading both copies of a library can be very useful to deal with the situation where one piece of code has been ported to v2 (due to bugs/features or just gener

Loading both copies of a library can be very useful to deal with the situation where one piece of code has been ported to v2 (due to bugs/features or just generally keeping up with updates) and another piece of code is hard blocked on the v1->v2 migration because it is much more costly, and its possible that v2 is actually buggier for that other use case. There's a bit of a naive idea that software always gets better for everyone and that projects have an infinite amount of spare time to drop everything to bump dependencies. That feature is actually very useful. (Which is not to defend the rest of the append-only immutability of the rest of the language, that looks a bit whack -- but then I've seen whack stuff get wildly popular, so I have no idea -- but while having 2 versions loaded at the same time might be useful I'm not sure I want to deploy every version that has ever existed that smells way too bloated)

torginus 5y ago
You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.
- lamontcg 5y ago
  Except 1.0.1 can fix a bug that one piece of code needs, while another piece of code can be happily bug dependent upon it. You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc). And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent to 1.0.0 and instead usually move forwards. And if you have a language that supports loading 1.0 and 1.1 then there's no point in being artificially constrained over which two versions can be loaded at the same time based on the label, the underlying framework shouldn't be built to care. There's no need for a multi-version library loader to care about what a bugfix is.
  - slver 5y ago
    SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.
    - lamontcg 5y ago
      We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework. Semver would just be an artificial impediment at this level.
      - slver 5y ago
        SemVer is an impediment only if you insist to make it so.
    - jonahx 5y ago
      Go takes an alternative approach: https://www.youtube.com/watch?v=wWApoImHuf8 https://www.youtube.com/watch?v=wWApoImHuf8
      - deleted 5y ago
        [deleted]
      - slver 5y ago
        That's not a new idea, I also put the version in my package name, so that you can use v1.x with v2.x etc. It doesn't contradict SemVer. However when you do that, it becomes a big deal to jump from one version to another even if the breaks are minor. So pros and cons.
  - uncomputation 5y ago
    (Mentioned xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/)
- fastball 5y ago
  I think another key idea is that you're still thinking about libraries as complete packages where you kinda install two versions of the same thing. But it seems more likely in the Unison ecosystem that you'd end up with the ability to much more easily only extract the specific functions you need. So say there is v1 and v2 of a utility lib in my dep tree, but actually only using func A from v1 and func B from v2. Then I just have the AST of v1.A and v2.B in my deps and everything works.
  - Nullabillity 5y ago
    You still need some unit of atomicity to be able to maintain invariants. You can't combine HashMap_LinearProbe::insert with HashMap_Chains::remove, because they both depend on implementation details in order to maintain HashMap's invariants.

torginus 5y ago

You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.

lamontcg 5y ago
Except 1.0.1 can fix a bug that one piece of code needs, while another piece of code can be happily bug dependent upon it. You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc). And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent to 1.0.0 and instead usually move forwards. And if you have a language that supports loading 1.0 and 1.1 then there's no point in being artificially constrained over which two versions can be loaded at the same time based on the label, the underlying framework shouldn't be built to care. There's no need for a multi-version library loader to care about what a bugfix is.
- slver 5y ago
  SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.
  - lamontcg 5y ago
    We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework. Semver would just be an artificial impediment at this level.
    - slver 5y ago
      SemVer is an impediment only if you insist to make it so.
  - jonahx 5y ago
    Go takes an alternative approach: https://www.youtube.com/watch?v=wWApoImHuf8 https://www.youtube.com/watch?v=wWApoImHuf8
    - deleted 5y ago
      [deleted]
    - slver 5y ago
      That's not a new idea, I also put the version in my package name, so that you can use v1.x with v2.x etc. It doesn't contradict SemVer. However when you do that, it becomes a big deal to jump from one version to another even if the breaks are minor. So pros and cons.
- uncomputation 5y ago
  (Mentioned xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/)
fastball 5y ago
I think another key idea is that you're still thinking about libraries as complete packages where you kinda install two versions of the same thing. But it seems more likely in the Unison ecosystem that you'd end up with the ability to much more easily only extract the specific functions you need. So say there is v1 and v2 of a utility lib in my dep tree, but actually only using func A from v1 and func B from v2. Then I just have the AST of v1.A and v2.B in my deps and everything works.
- Nullabillity 5y ago
  You still need some unit of atomicity to be able to maintain invariants. You can't combine HashMap_LinearProbe::insert with HashMap_Chains::remove, because they both depend on implementation details in order to maintain HashMap's invariants.