| HN Mirror

My comment was not meant to disparage the work that NASA does so apologies since that’s the way it landed. The engineers working on NASA are really good. I was just trying to convey that the requirements you have are very different from the general ecosystem and thus you will always have a greater cost to do engineering. Where possible, it’s always cheaper to relax constraints at the program level, not at the individual software component level (eg auxiliary components that have a recovery path in the case of SW faults). My impression is that NASA generally strives for highly reliable systems although I think they’re getting better with the Mars copter experiment. SpaceX is also doing good work trying to drive the cost down by making launches less expensive (that way SW faults aren’t as critical in most systems and payloads themselves don’t need high reliability because they can just retry).

On the dependency front, Rust solves this about as well as you can hope for at the language level since dependencies between components don’t imply anything else about the dependency chain. I was just trying to convey that at that point there’s no way I can think of to reduce the cost of upgrading unless you make agreements with your exact SW dependencies about what versioning and changes look like for them (for general OSS that’s not generally tenable as NASA is likely to be a very small use case compared with the number of environments a popular package might get deployed to). That works in some cases but there’s no way to enforce that and nothing any language can do about it.

Generally I’ve found that organizations ossify their dependency chain on the assumption of “if it ain’t broke don’t fix it”. I’m not sure I buy that because that’s just tech debt that starts accruing and it’s better to just always pay a little bit of money along the way. Of course I don’t have any experience running teams on the kinds of problem domains NASA focuses on so I can’t speak to which development process is better for that use case. All I can note is that using off the shelf software and reducing the reliability requirements on as many components as possible generally results in a cheaper outcome (eg the Mars drone). When you’re in that domain you’re out of the high reliability domain of expensive space rocket launches and into more of the traditional SW development processes. Generally I’ve seen Rust libraries do semver better than most since that’s culturally the expectation. Even with Semver though you’re stuck if the library authors decide to go to the next major version.