Stan is less than 10 years old, has over 100,000 users and created their own language (that gets compiled to C++ code). Their community, like some optimization sub-communities) have a history of creating their own languages, unlike numerical linear algebra that didn't need to because Fortran was perfect for it :-)
> On Jul 27, 2022, at 12:29 PM, Justin Chang <[email protected]> wrote: > > FWIW, vendors have poured a lot of effort into making C++ the industry > standard for HPC, and it will remain that way for a very long time. Switching > PETSc to a non-C/C++/Python/Fortran language today while still enabling > GPU/accelerated computing could get ugly from a code implementation > perspective. > > Not saying you shouldn't consider other languages, but if we want the most > seamless GPU experience then C++ is still the most pragmatic choice today and > for the foreseeable future. And it could become even more important on > tomorrow’s heterogeneous hardware architectures. > > On Tue, Jul 26, 2022 at 11:09 AM Barry Smith <[email protected] > <mailto:[email protected]>> wrote: > > >> On Jul 26, 2022, at 11:30 AM, Jed Brown <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. > > I would need to see some use cases of this to be convinced. >> >> 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? >
