[petsc-dev] PETSc future starting as a new design layer that runs on top of PETSc 3?

[Jed Brown]

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?
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220726/c10f4778/attachment.html>