It not just to use old Fortran code. Lot's of it is still being written in the scientific computing world.
There's also issues with wanting to use the old Fortran code in new projects and if the new alternatives don't have a good interface for Fortran, it's a bit of a pain to integrate.
Granted, there's plenty of fast libraries written in C/Fortran that don't have a Julia equivalent yet, and depending on the overhead of ccall(), you may wish to stick with writing the rest of your code in the language of the library.
My other problem is code generation. I can't generate Julia code yet.
Perhaps I am misunderstanding your meaning here, but Julia has a range of metaprogramming functionality including both Lisp-like macros, as well as "generated functions" that allow custom code specialization based on input type signatures (https://medium.com/@acidflask/smoothing-data-with-julia-s-ge...). These capabilities have been used for DSLs (e.g. https://github.com/JuliaOpt/JuMP.jl) and parser generation (e.g. https://github.com/abeschneider/PEGParser.jl).
C++ really crippled itself in this regard by never making a standard. I never bought Stroustrup's claims of "but you can write your own" for these reasons.
Just because they're good alternatives doesn't mean they merit rewriting software that cost millions upon millions to write the first time.
Plus when you're talking about code that runs on 5000 machines, even just a 5% difference is meaningful.
That said, I believe most of the post-MPI HPC frameworks are based on C/C++ with little support for FORTRAN.
Fortran is in a somewhat unique niche- basically anybody who uses a computer uses a library written in Fortran (via BLAS) but very few people are aware of it, especially that it has continued to develop and is actively in usd. There are plenty of places (mostly related to parallel evaluation) where Fortran is state of the art. But speaking as someone mildly competent in it, it isn't something everybody needs to care about. It has its niche and is pretty awful at everything else, best left to its little island of programmers. Haskell is my favorite language and C++ or Python are what I use in a professional setting, but I won't hesitate to break out the good old `IMPLICIT NONE` if it is the right tool.
It likely seems niche to most programmers, but array slicing is such a godsend to certain areas of software that there really is no more natural language to write a code in. There is Matlab, but its purpose is for prototyping. In fact it is a major credit to Matlab that the conversion is very natural.
This niche is why Fortran exists and has such a strong following. And the more modern features are like candy sprinkled on the core features. I could write a sonnet about modern fortran.