ESL language recommendations
Existing codes in the community are already written in a variety of languages (predominately Fortran and C++), which complicates the choice of language and makes it important to consider certain implementation choices carefully.
In order to ensure libraries can be used in as many existing and future electronic structure codes as possible, we prefer libraries to be written in C and/or Fortran. Further, we strongly recommend that libraries provide both C and Fortran bindings. Most languages have good support for C foreign function interfaces and so C is an excellent lingua franca. In particular, Fortran 2003 (see below) provides portable interoperability with C—please use this rather than the hacks required with earlier versions of Fortran!
Languages evolve and newer standards can offer some compelling features, making writing portable, efficient code faster and more pleasant. Given that codes use a large combination of platforms, compilers and libraries, supporting older compilers (within reason) is a good idea. As a result, it is important to test against different compilers and different versions within each compiler family to ensure you are not accidentally using a poorly supported feature. On the other hand, being stuck decades behind standards is counter-productive, so there needs to be a balance.
Broadly: C99, C11 and Fortran 2003 (excluding polymorphism) are fairly safe to use. Useful links:
Fortran 2003 interoperability with C
The iso_c_binding module in the Fortran 2003 standard provides a straightforward way of interfacing C and Fortran code. Extensive documentation exists online (e.g. on the Fortran wiki and GCC website). The key thing to note is that there are limitations on what data types are interoperable, especially with regards to allocatable arrays. It may be easier to write simple wrapper functions to handle this, especially if there won't be a major impact on performance.
Finally, note that it is often simplest if a code using a Fortran interface can include a module defining the interface in its source code. The impact of this on licensing is discussed more in ESL licensing recommendations.
Standalone post-processing utilities should be considered separately to libraries, as interoperability is no longer a concern. For these, python is already a popular choice in the community, as it is often more appropriate for post-processing tasks. If some post-processing stages are computationally demanding, consider rewriting those parts in C (or cython) for speed (as done, for example, in phonopy).