Comment by ivanperez-keera | Hacker News Reader

Comment by ivanperez-keera | Hacker News Reader

Parent Full thread

ivanperez-keera

I do not really know. I heard that it's generally perceived as a good option, but I don't know if any teams are actively using it for any missions.

My suspicion is that once it's generally accepted as part of the kernel, things may change.

If the rust community wants rust to be used in safety-critical, my personal view is that they need to prioritize robustness and stability of the rust ecosystem as a whole over frequent changes to the language or libraries to save 1-2 lines of code.

Breaking changes to APIs and tool changes are a big issue in general, so they are best avoided (almost every time some introduces a breaking change that we are forced to adopt, we have to spend thousands of dollars (in time) to adapt). It's best to take longer to release a tool, but when you do it, make sure it'll work for a long time.

We recently had this case with a tool and our project was delayed by several weeks because someone replaced a version of a tool in homebrew that introduced a breaking change. We hit multiple bugs during the upgrade.

A mission that flies won't depend on homebrew, but it would be very plausible for a bug to be fixed in a version that pulls a dependency with a higher version number, and for it to be impossible or impractical to upgrade only one or two packages. In particular (and I don't "speak" rust), if your compiler comes with core libraries that necessarily need a version of the compiler to work, you want those to be de-coupled and the core API not to change.

Please be aware that this is just my personal opinion. I don't speak on behalf of any agencies.

Specifically regarding this point:

> Breaking changes to APIs and tool changes are a big issue in general, so they are best avoided

There seem to be two different camps in the rust world. Any crates that have to do with web (orthogonal to but not distinct from async) or some GUI-related aspects seem to be constantly breaking in major ways between releases, way too often to actually keep up with. Anything else in the rust world, such that someone coming from a traditional C/C++ background would be interacting with, has a much more mature ecosystem around it w/ saner breakage (i.e. only when/where necessary and typically only changing a name or restructuring a type, but not "let's wholly rearchitecture both our own code and the code of anyone using this in the wild" kind of thing).

That's informative. Thanks!

Thanks Ivan, makes sense. With the ongoing work of integrating Rust into Linux, I hope we'll see some of that sought-after stability in its tooling. I appreciate the insight - I also wish more code was written with long term in mind, and by long term, I mean decades, not years.

This has been my issue too, and for a long time.

I've been betting on creating good software that survives for decades, but most people just want quick fixes and new features, and few are willing to put in the time to "do the homework" (that is, clean up the code, debug it, benchmark it, reduce it, modularize it, etc.). Over time, with more and more fixes and features, code rots and the maintenance burden increases.

People seem to be creating open source like it's free, with no regards for the time and effort put before. Every solution we create adds to the global maintenance burden of the community. We need to set processes in place that make open source code better over time, not bigger.

Not sure if you’re aware but in Rust there’s no dependency hell. Component A can depend on version X of a library and component B can depend on incompatible version Y and you can still link in components A & B into your program without any hassle/correctness/safety issues. That doesn’t solve the “but I want to upgrade to the latest version & for it to be compatible” but that’s typically an untenable position in any environment when relying on OSS - perhaps try to work out arrangements with those projects if possible to backport fixes instead if it’s that mission critical or live with developing processes to stay on top of updates like the rest of us?

One day I'll learn rust and maybe then I'll understand.

> live with developing processes to stay on top of updates like the rest of us?

NASA follows very robust software engineering processes (even for research projects like e.g., Copilot and, to a lesser extend, Ogma). It would not be able to do what it does if it didn't.

This is a topic for a longer discussion and definitely not to be had here, but I will say that it's not conductive to a constructive discussion to see it as a problem with our processes, or us ("developing processes to stay on top of updates", "like the rest of us").

The people who work on these things are smart. This is a topic we've had long discussions on. If it was obvious or viable to fix internally, we would have done it already.

I have been programming in particular in Haskell for 20y. I've worked for all kinds of companies and organizations, big and small, for the last 18y. I am like the rest of us. The problem is not exclusive to NASA, and NASA's processes are not to blame here.

It's a problem with how to build languages and ecosystems.

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.

There's a lot of things that you are not seeing. This problem is not specific to NASA, or to the safety-critical domain.

This is a topic for a longer discussion and definitely not to be had here.

Reply on news.ycombinator.com