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 <knep...@gmail.com> wrote: > > On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsm...@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/
