Who is using stdlib?

Following Ondřej’s @certik inquiry about the status of our Fortran community, I was interested to see whether any project already makes use of stdlib. From a quick search I could only a handful of open source projects on GitHub, however most of them were repositories for staging changes for inclusion in stdlib.

Is anyone aware of a larger projects which is using stdlib? Also, what is holding your projects back from using stdlib (size of the dependency, missing features, fypp preprocessor)?


Within the Fortran community, I see many people like duplicating and using only parts of a library instead of creating an explicit dependency on it, which could subsequently create dependency hell. This is especially true if the library is rather new and experimental (as is the case with stdlib). So, I would not be surprised if this question does not get many responses.


I am one of the devs of Fluidity a CFD adaptive solver. The main reasons why I haven’t attempted to modernise our codebase and incorporate stdlib is because

  1. the large size of our codebase, which also includes legacy Fortran
  2. and our external dependencies. We rely on so many packages PETSc, BLAS/LAPACK, Zoltan, VTK, ParMetis, SCOTCH (the list really is endless) and we deploy in quite a few different HPCs and OSs so we need to be able to guarantee that our code will deploy without too much hassle.

Other than that I don’t think there is anything else stopping us. I am pretty sure that we have developed similar methods to quite a few stdlib methods as part of our own FEM and linear algebra modules.


As @shahmoradi suspected, I have “vendored” a few key routines from stdlib, but am not relying on it directly for anything. My hesitancy is mainly to do with the fypp requirement and the size of the library. I think it’s a worthwhile project, but I suspect it will really begin to shine once the generics capabilities are added to the language.

1 Like

@everythingfunctional I just tested stdlib using fpm on my Apple M1 and everything built perfectly. I don’t have fypp installed and it is not needed unless you want to develop stdlib. In Debug (the default?) mode it took 27s to compile, but that’s because fpm currently compiles in serial (I think) instead of parallel.


Sorry to have to answer no instead of not replying at all, but I thought it worth commenting this: I wouldn’t expect a larger project using stdlib in the next few years, for a few reasons.

  • Most large Fortran projects are tied to slow (multi-year) funding cycles (science at universities and governments). They are developed slowly
  • There aren’t many new Fortran projects. Most Fortran development is in extending existing large and not-so-new projects, rather than starting new projects. Stdlib is very new, just over two years old. That’s a blink of an eye on the time scale of large Fortran projects. The benefit of replacing the working and familiar home-cooked stdlib-like functionality in these projects with stdlib is probably more trouble than worth it.
  • Many large Fortran projects are not open source. If they do end up using stdlib, we won’t know about it unless somebody reports here or on GitHub.

That being said, I expect stdlib to be used more broadly in toy projects, especially via fpm.

I have not used stdlib myself except in never-published small toy projects, and especially since stdlib became fpm-able. Stdlib becoming usable via fpm was the turning point for me to use it in small experiments.

Granted, I have not programmed Fortran professionally very much since stdlib started. Nowadays my programming workload is about 10:2:1 for Python:JavaScript:Fortran, as much as I wish it were different. Since the start of stdlib, I’ve only had one non-trivial (~3K LOC) Fortran project with six large dependencies. I just scanned through the code and it looks like I could only use stdlib for kind constants, but nothing else. So, for me, I guess I’m still waiting for a Fortran project in which I’ll need stdlib.


Though I agree with you, I’d still call this “using stdlib”. :slight_smile: I think that directly inserting a source file instead of using a dependency the “proper” way may suggest that it’s just easier to do it that way, and I’ve done it many times before.


stdlib currently has a good complement of Fortran built-in functions on general algorithms, I’ve fallen in love with fortran-lang’s fpm and stdlib, I use fpm in vs code, with the updates of the Modern Fortran plugin and Fortran language server (Thanks @gnikit a lot), The experience is getting better.

At present, stdlib and fpm still have great potential. At least stdlib has not yet connected to the perfect lapack interface. At least we don’t have inv, det, and other array calculation, which are the strengths of Fortran; fpm will become more and more easy to use as it continues to develop, of which I’m expecting improved ease of use for linked libraries in my local disk not only from the Internet.

It does take some time to compile stdlib, but if it is compiled and placed on our local disk, it is reasonable to use fpm to call it:

  1. Use CMake or fpm to compile stdlib;
  2. Store stdlib on the local disk and set LIBRARY_PATH=<path of stdlib>
  3. Configure fpm.toml:
external-modules = ["stdlib_strings"]
link = ["fortran_stdlib"]

include-dir = "../../inc/fortran_stdlib"

At present, stdlib is more convenient for ordinary users to write some small projects (maybe behave like numpy?) and learn common algorithm writing methods with certain consensus. fpm and stdlib make Fortran users feel that there are still more possibilities. As one of the basic languages, scientific computing language (Fortran) is really suitable for open source co-construction and benefit from open source.

Other links


Absolutely, I only meant to broaden the definition of stdlib user beyond explicit dependency. I am one such user inspired by the stdlib’s optional argument handling module. I ended up (re)implementing the stdlib module for my use case for three reasons: 1) I did not like the current interface, 2) “no dependency on any external library” rule for the package under development, and the need to extend the stdlib interface to other scenarios.
It would be great if stdlib modules are (re)designed to be used as independently as possible from each other. It will extend the userbase of the library over time. As evidenced by the above comments, most developers are hesitant to add a new dependency on a large library whose interface is still evolving. However, I bet many people would want to use parts of the library relevant to their work if the module-inter-dependencies are minimal.
It takes quite a while to gain users’ confidence in a library. It’s too early, in my opinion, to make any judgments based on the number of users who have an explicit dependency on stdlib. It’s a great worthy project that should be continued. Is there a vision statement for stdlib somewhere? If not, it would be good to have one.


I agree, we need to get the linalg module to call lapack and provide a nice high level interface, then it will become very useful to many people.


Recognizing the value, it looks like someone has already done this splitting of the stdlib for their usage (link was by @zoziha in the above).


@shahmoradi let’s discuss the splitting in Idea: Splitting stdlib into smaller separate libraries. If you could write your opinion there, that would be awesome!


I feel like the fypp preprocessor makes the codes look not so Fortran. I once looked for a normal distribution function in the stdlib. When I saw the preprocessor stuff, I instantly gave up.

1 Like

My experience is very similar to what @milancurcic describes. Most of my Fortran programming at the moment is on old(ish) projects which already have their own home-baked versions of stdlib utilities. I haven’t had a chance to either update these to use stdlib (definitely on the radar for some of the bigger ones) or start new ones using stdlib.

I also find myself writing more Python than Fortran, especially when performance isn’t critical, which has historically been because of easy access to utilities like those provided with stdlib, package management and ease of use in Jupyter Notebooks. All of these are things being addressed by Fortran Lang and so I see myself having fewer and fewer reasons to turn to Python in the future. I suspect a lot of folk and projects are in the same situation.

So, give it a few years and I reckon stdlib will be ubiquitous!


I am using stdlib in one of my work projects. It is a library, which defines functions to store and load variables to and from netCDF files in MPI applications.
The only role of stdlib is optval and the logger. Maybe I will use the strings from stdlib in the future.

If stdlib wouldn’t be available via fpm, I wouldn’t use it for this project.


I expect I’ll slowly start to use more of stdlib. Right now I just am using the save_io_npy routines for a smaller project. However, on the cluster I’m using given the package management, I had to not use stdlib but the original NPY-For-Fortran repository on GitHub, as stdlib seemed to have more modern requirements than what my cluster could [easily] provide. (I probably could have made stdlib work, but it was easier to grab the routines from NPY-for-Fortran).


I use stdlib in one of my largest (not open-source) project (> 25K LOC), mainly stdlib_logger and stdlib_sorting.
Through fpm, I use it daily with other fpm-packages for handling files, computing descriptive statistics, … Note that, without fpm, I would probably not use Fortran for these tasks, even if it would have been slower for some of them. Based on the comments of this thread, it really seems that supporting stdlib in fpm was an important step for stdlib.

I don’t see the compilation time as a problem (except if I develop it :wink: ), because it can be compiled once, and doesn’t need to be compiled each time (like BLAS/LAPACK, or other libraries I use as a user). And I believe that the issue with fypp is not a true one. Indeed, generated code could be provided, as for fpm.


We should start adding high level modern Fortran linalg to stdlib and by default use the Fortran reference lapack: Maintain fpm installable lapack under fortran-lang?

Both stdlib and lapack provide high performing default reference implementation. And then vendors are free to substitute by even higher performing versions (MKL, OpenBlas; and the same for stdlib down the road).

Once stdlib has linalg via Lapack, I think I would use it too in new projects, almost by default, as linear algebra is almost always needed in any numerical code.