It is true that ifort produces code that is sometimes 2-5× faster, but the compiler is also currently buggier than gfortran IMHO, even on basic stuff like sum()

It is true that ifort produces code that is sometimes 2-5× faster, but the compiler is also currently buggier than gfortran IMHO, even on basic stuff like sum(). And the produced code is harder to debug: the backtraces aren't that great and I couldn't get them to work on stop/error stop, unlike Gfortran. Gfortran can produce reasonably fast code with array bounds checking enabled, but ifort turns off optimizations if you enable that, which means that you can't debug your code because it takes forever to run. Gdb has trouble with both ifort and gfortran code and ends up panicking if you try to inspect variables a bit too closely. But then I rarely use a debugger. As far as language support goes, neither ifort nor gfortran properly supports parametrized derived types, which is a pretty sweet feature that allows you to define a small number of dynamic type parameters that define things such as dimensions and precisions. This saves a lot of boilerplate regarding allocation and deallocation and makes the code cleaner. However I got burned using that, as ifort ends up crashing as soon as the code making use of PDTs gets complex (for example, as soon as you've done implementing your module and are using it in some bigger piece of code) or produces incorrect code. Hopefully they'll fix that soon. Both ifort and gfortran do support the object-oriented and generic features, although wrapping your head around the Fortran memory management and allocation model is difficult if your background is C. Fortran lacks direct support for generic programming, but you can work your way out of that pretty decently with creative use of modules and the 'include' directive, without even needing to use CPP. If you're gonna use CPP, keep it simple, #ifdef's etc. are OK, for macros you need to define your own concatenation operator if you want your code to work both with gfortran and ifort. As for PGI Fortran, it doesn't even fully support object oriention, so it's more like Fortran late nineties; but it does do fancy automatic parallelization and can target GPUs. The reason people still use Fortran is because it supports arrays, is fast, readable and standardized. No, C and C++ do not support arrays. Proper array support would involve the compiler knowing array rank, dimensions and eventually stride, providing standard ways of representing and indexing them, and basic functions with clear performance and memory management properties, plus bounds checks (and the ability to optimize them away). Now let's pretend you have some C++ header library that provides some of that in the form overloaded indexing operators etc. Will that stuff compile in two years? No it won't, because the library will change, and because the compilers will change. It's not standard. Second, your C++ code is gonna be unreadable. Fortran code is readable to Joe random Engineer/Scientist, + means plus, and an array is an array is an array, and hasn't changed much in decades. However, general I/O in Fortran is horrible, although the edit descriptors allow you to produce nice fixed-column output easily as opposed to printf. Also, you can "print , any, value, you, want" which is very handy for debugging, but C++ streams generally cover that.