These ownership patterns need to be addressed for reliable interfaces in any language, the compiler just forces you to do it (or use the unsafe escape hatch) in Rust.
I think it's necessary in any incremental porting effort for "old" code to call "new" code, due to the nature of our composition and callbacks. On Tue, Jul 26, 2022, at 8:17 AM, Jeremy L Thompson wrote: > I feel like someone has to mention the possibility of Rust. > > In libCEED, we've found the FFI to C fairly painless. We made some > improvements on the core C code of libCEED to facilitate Rust error handling > and data ownership. > > From various prototyping we've done in Jed's group, I think the more complex > data ownership used in PETSc (as compared to libCEED) is one of the more > complex issues that would need to be planned out for a Rust focused interface. > > On 7/25/22 15:34, Barry Smith wrote: >> >> A major problem with writing a completely new version of a large code >> base is that one has to start with nothing and slowly build up to >> everything, which can take years. Years in which you need to continue to >> maintain the old version, people want to continue to add functionality to >> the old version, and people want to continue to use the old version because >> the new version doesn't have "the functionality the user needs" ready yet. >> >> Is there an approach where we can have a new PETSc API/language/paradigm >> but start with a very thin layer on the current API so it just works from >> day one? >> * to this would seem to require if PETSc future is not in C, there has to >> be a very, very easy way and low error-prone way to wrap PETSc current to be >> called from the new language. For example, how petsc4py wraps seems too >> manual and too error-prone. C++ can easily and low-error prone call C, any >> other viable candidates? >> >>
