So why is NWChem being re-written in C++, and what relationship does that have to exascale? Richard O'Keefe said 10 years ago ago "Why not start by rewriting the Fortran code _in_ Fortran? Fortran 90 is a very pleasant language." (NWChem is just in Fortran77 as far as I remember.)
I work in HPC, though I don't write numerical code these days, but I'd definitely prefer to write it in Fortran than C, and I'm not clever enough to use C++. I'd also much rather maintain typical scientific Fortran.
In my opinion, Fortran will fall behind as newer hardware, libraries, etc, will drop Fortran support. Also, newer grad students are all much more interested in C/C++/Python. I think this is in part because the newer languages are widely used outside of science and therefore there is much more documentation and tutorials/guides. Not to mention that skills in those languages are transferrable to other areas (data science, machine learning, etc).
As a side note: Wow someone working on the ECP on HN? I'm tangentially related to the project (and just visited PNNL last week)
Really? Seems to me that with very few exceptions (e.g. GPAW which is python/C and nwchemEx which I've never heard about until the parent poster mentioned it), electronic structure is pretty much a Fortran bastion.
(Source: I did a Phd doing mostly electronic structure calculations, graduated ~5 years ago)
New libraries are being written in C/C++, and maybe Python. This includes libraries that should form the foundation of the QM community (matrix/tensor and integral libraries). These are meant to take advantage of newer hardware and libraries which themselves are written in C/C++, and often in a way that is inaccessible from Fortran.
The old Fortran code will be around for a long time, but I don't know of any large-scale, serious efforts to develop new packages or major new functionality that are starting with Fortran.
(I'm not totally against Fortran - I just spend a week devloping in it. But I still much prefer C++ and Python)
I'm afraid you need a 10-, or preferably 20-, year perspective, not a week.
About C compatiblity: Many C libraries use pointers in their interfaces. Interoperability is indeed defined by the Fortran 2003 standard, which I have used several times to wrap existing C libraries. However, much of the existing code is F90 only (some even F77...), and a vast majority of Fortran developers in the field are not familiar with even modules and other F90 features, let alone iso_c_binding in 2003.
Also, newer libraries tend to be C++ as well, which is more difficult (or at least more awkward) to wrap.
Finally the fact that groups like Facebook and google are writing their machine learning code in C++ shows that 1 they find it useful and 2 plenty performant. This kinda became a response to the comment above yours sorry.
If you don't feel like it, feel free to ignore.
My background is in QM, so I guess that's my bias showing through :)
Somewhere under http://www.archer.ac.uk, there's a summary of the time used by various codes on that UK "Tier 1" system.
On the parallel front MPQC has been around a long time and is C++.
Modern Fortran has many nice features in 2017, but the people that wanted these features moved to C/C++ long before the features became available in Fortran and those that are left using Fortran are usually scientist, not programmers, and so don't care so much about these features. I think it is largely the older generation that says they will never stop using Fortran, in the survey mentioned in the article.
Just to suggest where the field is moving though. NwChem is a large successful electronic structure package using Fortran. Its next gen version NwChemEx that is being designed for exascale will exclusively be written in C++ (https://www.pnnl.gov/science/highlights/highlight.asp?id=441...).
Also just from experience people who work in HPC mostly would rather be writing C/C++, but use Fortran because they have to not because they want to.