<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I feel like someone has to mention the possibility of Rust.</p>
<p>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.</p>
<p>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.<br>
</p>
<div class="moz-cite-prefix">On 7/25/22 15:34, Barry Smith wrote:<br>
</div>
<blockquote type="cite"
cite="mid:941B4E85-D4E0-4634-8E69-4AE0950C649B@petsc.dev">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class=""><br class="">
</div>
<div class=""> 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.</div>
<div class=""><br class="">
</div>
<div class=""> 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?</div>
<div class="">
<ul class="MailOutline">
<li class="">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?</li>
</ul>
<div class=""><br class="">
</div>
</div>
<div class=""><br class="">
</div>
</blockquote>
</body>
</html>