I’m not a Rust expert. I really like Rust though and thus was happy to hear that some Rust code had founds way into Nix. This is something that I was aware of prior to the call already. I hadn’t looked at it though. I was less enthusiastic about what I learned during the call in terms of how the C++/Rust interop actually works.
During the call some time was spent arguing about the ways in which this could break, segfault or lead to undefined behavior. I don’t have the insight to make statements about the likelihood of things breaking in horrible ways. But frankly I’m not sure I need to:
While there were different opinions on the likelihood of things going wrong and just how bad things could go wrong it seemed to me that nobody in the call argued that this was a nice and clean interface - this, as far as I understand, simply isn’t currently possible.
From my point of view we are thus dealing with tech debt. Adding tech debt can be completely fine and a good way forward. I think there are just some constraints to doing so successfully and responsibly:
- Has to be added consciously and explicitly
- Has to be the result of some cost/risk/benefits considerations
- There has to be a plan of how to repay/reduce it
I would be really interested to hear opinions on the above bullet points in the context of the Rust code that has been added to Nix and the way forward. I am thinking and wondering about:
- What could a nice, clean and stable interface for Rust look like in the future?
- Should more Rust code be added before such an interface exists?
- What is the benefit of having the Rust code we have right now considering the risks versus f.ex Decompress tar files using libarchive by yorickvP · Pull Request #3259 · NixOS/nix · GitHub ?
- What could be a plan for an incremental transition from C++ to Rust? Maybe the current approach was more of a spike and now it’s a matter of figuring out how to do it in a cleaner and safer way?