Never or ever? I have to use it for a work project. It's ok when dealing with numbers or matrices, but very painful in many respects. It's missing quite a few features found in more recent languages. I don't recommend it personally unless you're working with other big fortran codes.

* Missing standard data structures, like hash maps. I just wish I had something like a Python dictionary built in.

* Strings are pretty awful. You can now have resizeable strings but using them is very painful (and buggy in gfortran). You'll have to constantly strip spaces off the ends of strings to even print them.

* Some of the compilers are very immature (gfortran), if using any fairly recent features (e.g. resizeable strings). I've hit several (still unfixed) compiler bugs and my code contains some terrible workarounds.

* Available libraries are hit and miss, particularly outside the numerical area.

* Linking to C/C++ is possible, but painful with the binding support.

* Documentation (including books) just isn't good compared to what's available for C/C++/Python, etc.

* No templates (would come in very handy for some routines which handle different numerical types).

* Ok for numerics, though can't use C/C++ intrinsics for AVX/SSE maths.

I suppose what I like better than C/C++ is the module system and built-in support for N dimensional arrays with proper slicing, etc. The allocatable array thing is quite nice - it's like smart pointers in C++.

Thank you. I agree with all of this, and that is precisely the reason why I decided to get involved to make things better. To fix all of the above I believe we need:

* Much better tooling and more organized community, thus we started https://fortran-lang.org/ and the associated projects (fpm, stdlib, ...) and discussion board (Discourse)

* Better compiler that has good support for all Fortran features, and can help with linking and using C++ and Python libraries (automatic wrappers both ways), better optional warnings (to prevent old style code), good support for GPUs, etc. Also interactive like Python or Julia. I started LFortran (https://lfortran.org) to fix that.

* Perhaps some improvements to the language (I joined the Standards Committee and I encourage people to join). We have a subgroup for generics (templates). The hash maps should probably go to stdlib first, later we can think about putting them into the language itself.

It depends on what you are doing. If it is numerical work with matrix operations, then Fortran is fast and pretty intuitive. Some of the annoyances come from dealing with legacy code and mixing it with modern standards.

Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has.

This isn't any better or worse but does require a shift in mind set.

Though I believe some people are trying to build a Fortan Repl

> Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has.

I mean, yeah, Fortran is a bit old school, but being compiled is not exactly old school. Plenty of modern languages are compiled. I'd even say that Python and JS are the odd ones out from a modern perspective.

It might be a bit of a shock for those coming only from interpreted languages though.

That's true, I keep forgetting about https://lfortran.org/ Unfortunately in my experience the people I know who almost exclusively code in fortran are not really interested in jupyter notebooks.

Indeed, I expect it will be newcomers to Fortran from languages like Python, Julia or Matlab who will really like LFortran once it matures. We are working very hard on it and are close to compiling real world projects, you can follow our progress on MVP here:

https://gitlab.com/lfortran/lfortran/-/issues/313

Current Fortran programmers might not always appreciate the interactive part, but I think they will also like LFortran as another independent compiler and for some of its features once it matures (such as C++ translation, fast compilation, good warnings, automatic wrappers to/from Python, etc.).

Nail on the head with the mixing of standards. Every FORTRAN codebase Ive had to use at work always has a mix of 77, 90, and even pre 77 code mixed all together

I do an awful lot of baseball stats work .. for fun .. and quite a bit of it is done in FORTRAN. Working with numbers, large matrices and some pretty hairy calculations is much easier, to me, that using R or Python. There are also some really nice libraries available.

Of course, you have to overcome decades worth of ``stuff'' but it certainly is the right tool for what I am doing. It has a purpose but there is a learning curve to getting things done the FORTRAN way.