Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Couldn't much of the function of such a "platform" be automated?

One of the main constraints that would guide selection of crates for this platform metapackage is that they must have compatible dependencies. So package A depending on Bv1 and package C depending on Bv2 wouldn't work because they Bv1 and Bv2 would both have to be included, leading to a conflict.

But this information is (in theory) encoded in semantic versioning. Assuming proper semantic versions for crates, a target set of crates to be included could be specified, and then automatically the various sets of crate versions that do not have conflicting dependencies could be calculated.

These compatible crate/version sets could be automatically generated and published as metacrates.

Consider the following crate/version dependencies:

  Av1 -> Bv1
  Cv1 -> Bv1
  Av2 -> Bv2
  Cv2 -> Bv1
  Av3 -> Bv2
  Cv3 -> Bv2
compatible_sets({'A', 'C'}) returns {{'Av1','Cv1'},{'Av1','Cv2'},{'Av2','Cv3'},{'Av3','Cv3'}}

By imposing an ordering on these compatible sets they could be automatically identified. compatible_A_C_0 is {'Av1','Cv1'}, compatible_A_C_1 is {'Av1','Cv2'}, and so on.

Obviously the semver could be wrong and unexpected incompatibilities could crop up. But couldn't these just be autogenerated and then voted on? Then the top best compatible sets will filter to the top and, de facto, the Rust Platform has been autogenerated?



  > So package A depending on Bv1 and package C depending on Bv2 wouldn't
  > work because they Bv1 and Bv2 would both have to be included,
  > leading to a conflict.
As mentioned in this thread, this already works just fine. Rust can handle both versions.

Furthermore, it's more than just a constraint problem; there's also integration issues, testing the whole thing together, etc.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: