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

[Jacob Faibussowitsch]

IMO C++ is the pragmatic choice here. 

- Anyone with a C compiler is virtually guaranteed to have a C++ compiler these days, so no extra toolchain burden on users.
- Our configure and build system already has all the infrastructure in place for C++ builds.
- We already do half-C-half-C++ in the codebase, so users would actually never notice.
- Modern C++ truly isn’t the unwieldy beast that C++03 was. Algorithms, the container library, and all the additional type safety no longer requires the insane template verbosity that it once did.
- C++ has by far the widest user-base and adoption among all choices given, and given the heavy buy-in from corporate America we are guaranteed that C++ will see continued support for years (if not decades) to come.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Jul 26, 2022, at 08:30, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsmith at petsc.dev> 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?
> This looked like the most promising thing about Zig. We could develop the new modules alongside the existing C, and throw them away
> if we decide it is not worth it.
> 
>    Matt
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/