We’ve all been anticipating it, and it finally happened. Fortran (with COBOL) is now in the TIOBE Top 10, at a level comparable to the early 2000s! The really good part is that the growth curve is still increasing sharply.
If anything, this is testament to the sound scientific computing design principles behind Fortran, and the constant efforts of the Fortran community to improve the language and the standards.
Congratulations!!! 
There’s a long-running thread about it here on the forum, but yeah! This comeback is a good thing, too. Goes to show that in the end, people stick with the tools that get work done. Just like a friend of mine who needed to process some business records, and after looking at some modern solutions he just got himself a Cobol compiler and used the language he already knew well. And I taught myself Fortran just last month (then joined this forum) because it works for me. It’s that simple. Never mind that scientific computing – in particular data science – continues to grow, and a rising tide lifts all boats.
Any publicity is good publicity may be apt for Fortranners in this instance.
A better index is IEEE Spectrum The Top Programming Languages and unfortunately, it’s yet to catch up.
The deserved place for Fortran is truly and permanently in the Top 5. And with just a few basic additions and extensions to the language standard, Fortran can greatly enhance its suitability for so many computing tasks. These are only extensions that, in terms of feature sets, languages such as Ada introduced back in the 1990s. Thus no pathbreaking computer science is needed here, Fortran can really catapult itself to the top and stay there by simply working hard and diligently and with vision as @certik and team do with LFortran. That is exactly what Backus and team did with FORTRAN I in the 1950s at IBM.
It is only a failure of imagination holding back Fortran whereas leaders such as @certik have shown to anyone who cares to observe what can be achieved in such a short span of time. And this is possible because the language always illustrates the potential of safe and simple syntax and semantics.
So much more is achievable with this language.
Definitely Fortran remains the only viable candidate as a full spectrum lingua franca of scientific and technical computing.
@FortranFan Looking at the 2023 and 2022 IEEE rankings, which is when they started reporting comprehensively and not just the top 10, I see that Fortran went from 0.59% in 2022 to 1.86% in 2023. This agrees with Fortran’s rise in popularity reported in the TIOBE index.
Note as well that in 2023 Fortran overtook both Julia and Cuda, and is the 6th most popular scientific programming language (after Python, C++, C, R, and Matlab). That’s flirting very closely with the top 5 you mention, and indicative of renewed global interest in the language from the scientific/technical circles. BTW the top 3 have a much broader application base, so a basic 1 to 1 comparison is not really suitable. With Matlab at 5%, I wonder how much of it is devoted to applications common with Fortran. The two languages are probably much closer.
The Fortran community has good reasons to celebrate the latest rankings, both from TIOBE and IEEE. There is no failure of imagination holding back Fortran, as it is still a very serious player in both commercial and academic software.
Not clear how they did the ranking?
Would have been interesting if they had dived a little deeper.
SQL is 1/3rd as popular as Python - but they are hardly alternatives…
Erlang and Elixir could be merged - at least when comparing with other languages - since they are based on the same virtual machine.
Same for Java/Clojure/Kotlin.
In a parallel timeline, Fortran could have been the language of machine learning. Perhaps not general purpose enough to become the main choice in computer science departments…
You can still get a job today as a Fortran programmer—although you’ll probably need to be able to get a security clearance, since those jobs are mostly at U.S. federal defense or energy labs like the Oak Ridge National Laboratory.
Not only I think, but it is probably not “Fortran programmer” it says on the job description.
@zbinkz very interesting. I’ve been looking for some other independent statistics for Fortran, not just TIOBE. I wasn’t able to find the numbers you are quoting at the IEEE link. Can you please point me in the right direction? They don’t seem to show the percentage for Fortran.
@certik if you click on an entry, a pop-up window will open with some statistics. Only available for 2022 and 2023 so far. See screenshot below…
Regarding the ranking within scientific computing languages, I parsed the list by hand. Old school 
Ah I see, I didn’t realize you can click on it. Thanks!
Indeed, huge improvement! It would be interesting for them to do 2024 and see if the trend continues.
P.S. The 2023 is normalized to 1, the 2022 to 100. You have to click on 2023, but hover over for 2022.
@certik yeah IEEE seems to be in a format flux lately. The 2023 iteration is pretty good, and I’m looking forward to what 2024 will bring… 
The evidence suggests there indeed is “failure of imagination”: if one cannot easily bootstrap modern Fortran in modern Fortran itself, that is utterly shameful and there are some serious gaps someplace.
LFortran development:LFortran embarked upon around 2019, about 15 years after the iconic Fortran 2003 standard publication.Such an endeavor would have readily exposed some of the glaring gaps in the language that hinder large-scale development of codes for big problems and applications, particularly those needing to work with massive amounts of data, and which is entirely common these days for any technical and numerical computing. And that would have tremendously helped the Fortran language development. Anyone can study the underlying C++ code for LFortran and note a good string type (“class” in OO parlance) in Fortran and a few other basic goodies would greatly have made modern Fortran viable as a compiler development language for Fortran, maybe not in the LLVM space but that’s another story.
By the way, Fortran must always keep in mind the logical fallacy (!!! 
) of “No true Scotsman”:
Unfortunately too much went wrong with Fortran after the Fortran 2008 standard revision until @certik et al. turned things around so amazingly for Fortran, including with this Discourse site.
Such an imagination and vision, as shown by @certik, is needed for Fortran to rightfully take its place in the permanent top 5 at Tiobe Index and also the IEEE Spectrum survey. Imagination can make this happen.
I think we want Fortran to be better than C++ to write scientific numerical codes, and I think it is.
I don’t know if Fortran must be better than C++ to write a compiler. It’s true that writing a compiler is a large project and so reveals the maturity of the language, however I think we mainly want to reveal issues with Fortran for scientific applications. There are still quite a few issues there to fix. So I would focus on that, rather than focusing on improving Fortran for compiler writing.
I have an idea that I have no idea if it is easy to implement…… but is it possible to provide some C APIs for the parser part of LFortran? If we could write a Fortran wrapper on top of these C APIs, we immediately have a “Fortran parser written in Fortran”. This could potentially helps, for example, fpm to catch more information from Fortran source code. Other tools like LSP and Fortran formatter can be built with pure Fortran as well. Currently all these infrastructures rely on C/C++/python, and one need multiple package managers to build a Fortran ecosystem, which is not ideal. If fpm-registry gets mature and all these tools could be written in Fortran, in one day maybe, we just need a single line
fpm install fortran-essential
to install everything needed for Fortran programming.
@FortranFan computing is an ever changing landscape, and even more so the last 10 years. Your points about bootstrapping and the logical fallacy are in fact subjective opinions amongst many out there. Could have, should have, and would have don’t matter. What matters is the reality on the ground, which is that the Modern Fortran approach is working really well, and propelled Fortran adoption significantly as shown by the objective statistics from TIOBE and IEEE.
I don’t care if the compiler is written in another language as long as my code is fast and optimizes well. Fortran BTW still optimizes better than C++, and that is due in great part to the heavy OO nature of C++, and the liberal use of pointers (IMHO as both a Fortran and C++ developer for HPC applications where we live and die with efficiency, speed, and scalability). This said, C++ is still a great language to write a compiler, and there is no shame in using it. Take it from a guy who cut his teeth on Fortran 77 in the late 80s, and learned to be pragmatic the hard way.
More to the point, Python (the most successful programming language on IEEE rankings for the last few years) has a significant C++ source base. It is also interpreted, so the compiler is a non-issue here. Lastly, the fast code in scipy is in fact Fortran.
There is no more room nowadays for purism in computing. Many languages intertwine, and bindings have become a must have. A software developer is expected to master at least a couple of leading languages, and have reasonable experience in half a dozen more. Most software projects use 3 or 4 different languages today.
@certik The future of Fortran is really bright, and innovative projects like your LFortran will only make it brighter. Fortran is better than C++ for what it is meant for, and I don’t think we should try to emulate C++, which is far more general than Fortran. More so, there are a dozen software projects out there aiming to simplify C++ because there is consensus in the community that the language has grown too complex to handle. We should really be mindful of that in the Fortran community. OO is not always a good thing, and certainly not good for performance, which is the biggest reason one uses Fortran. I can still write very efficient and fast f90/95 code that will smoke any OO C++ code out there.
That may have been true in the past, but recently many of the Fortran parts have been replaced with native Python implementations. See META: FORTRAN Code inventory · Issue #18566 · scipy/scipy · GitHub. The two major reasons driving this replacement are 1) lack of SciPy contributors skilled or interested in Fortran, 2) build difficulties on Windows.
Compilers are not that cheap to develop, for example this webpage estimates the development costs of GCC 9.2 and LLVM 8.1 over $500,000,000 each. It appears reasonable to assume the bottleneck in writing a good compiler is the amount of developer hours. Most computer engineering programs teach C++ nowadays. For example at the Technical University of Munich, the students follow the book by Wilhelm and Seidl (Compiler Design: Syntactic and Semantic Analysis | SpringerLink) which focuses on a subset of C++. Also at Chalmers University in Göteborg, Sweden, the courses focus on a subset of C++ (Implementing Programming Languages).
If we look at the weekly statistics of Compiler Explorer usage (godbolt.org → Other → Statistics), you’ll see a heavy bias toward C++,
These numbers need to be taken with a grain of salt as we don’t really know what are the usage patterns, and we can interpret these numbers in many different ways. Maybe the Fortran number is lower because most of us are happy with the performance we get, without needing to study the generated assembly.
The numbers do appear relatively consistent with the TIOBE index, e.g. C# (#5), Go (#7), Fortran (#10), Swift (#12) all fall within the 5000-8000 interval. On the other hand, there appears to be a disproportionate number of Rust and Zig compilations when compared to the TIOBE rank of these two languages.
The compilations over time shows another aspect,
There is a clear work cycle, with less compilations on the weekend (06/08 and 06/09) and a bimodal daily pattern (could it be the lunch break? maybe programmers in the US and Europe?).
Yes, we already use that for the WASM version here: https://dev.lfortran.org/, we call LFortran from JavaScript using a C interface.
Yes, that is indeed our goal, and we even have funding for that work lined up, so if anyone is interested to work on that and get paid, let me know.
Well, not for long unfortunately. They are moving it to C++.
Well, under one condition: we have to build the full ecosystem. High-quality opensource compilers, fpm, stdlib, tutorials, website, reform the committee a bit, etc. We need help with all this work, it won’t happen on its own. 
I would suggest you to argue “scripting languages and programming languages are different”, so that python is no longer a programming language, and the great C/C++ can take its crown back(!!! )
Funny coincidence, I wrote not long ago that programming languages can be roughly divided by intended role into systems, application and scripting, and conflicts appear when a language designed for one role is forced into another. This is relative: Python for example is widely used for application development, and so is C++. Sure enough, both languages have become too large and complex for their own good, trying to be everything to everyone.
Now, Fortran. It seems to me that most people here want Fortran to remain a language for science, but that’s a niche, even with the rapid growth of statistics, simulations and all that. And as long as it’s a niche language, it will have a hard time attracting enough programmers to popularize it, write libraries and influence the development of compilers + the standard.
(That’s something all fandoms struggle with, by the way: being torn between wanting to be popular and widely accepted on the one hand, and staying a cozy space on the other.)
Here I am, an outsider who likes Fortran for what it is, even if I’m no scientist, and even if it has flaws that would make it hard to write a modern compiler in it; for example, I’m still unclear on how to read input lines of arbitrary length. But even if the language can’t easily do that yet, it can still be useful for a lot of things, and besides, you can’t get very far if you don’t push the limits. People write Lisp interpreters in Awk!
First things first: the general public needs to know that 1) Fortran is still a thing, not just a retro curiosity 2) it’s a modern language, not stuck in 1977 3) it can be used for a lot more than raw number crunching 4) it’s incredibly easy to learn 5) it’s different, not just another C replacement.
I’m not sure what will help. Some of that has to stick.
Some people also like the RedMonk language ranking, they don’t give numbers, so I am estimating it from their graph using the popularity on GitHub, as percentage (I am guessing it is normalized to the most popular language):
It’s really hard to estimate, but one can see that year to year it is clearly moving up in the ranks. It seems it was slowly dropping until 2019 (the years 2012/2013 have weird normalization in the graph), but the last 5 years it’s been steadily rising.
I haven’t checked lately, but thanks for pointing that out. Still, it does not take anything from the performance capabilities of Fortran.
I checked the methodology from the page, and it should be taken with a grain of salt. Ballparking the cost the way that guy did it is not representative of commercial compiler development for example, where you’d be quickly out of business cause this would be a prohibitive cost to pass down to the customers. No way you’d be profitable with such capital cost. Commercial compiler developers are much more cost-efficient, a couple of orders of magnitude less.
But I do agree that the bottleneck in compiler development would be developer labour.
Sure, one needs to have a full offering (or close) to be competitive. However, there are many things like graphical output and GUI development that other languages are much better suited for by design. It would be very helpful there to offer good bindings to these languages (you know who I’m talking about ). For this old dog, Fortran is primarily an efficient number crunching beast, and we should not stray too far from that. We’d get shot down by the competition faster than Fortran can add two integers.
