Hi all, reviving the post as redirected from Who is using fortran-lang projects (fpm, stdlib, minpack, fftpack, vscode-support)?.
I’m a new stdlib user, for my first “from scratch” new fortran project (which I haven’t yet announced here but might do in a few weeks: it is currently under thorough “real-use-case” testing, running my PhD stuff in a HPC cluster and I definitely see some final additions and fixes before it becomes a real first working version).
I wanted this project to be developed fast and clean so I aimed at outsourcing everything that is not too specific to the core algorithm. Well, probably the exact opposite of what Fortran development has looked in the past…
Hence availability with
fpm was a crucial requirement for including a dependency, in total alignment with this:
Especially since I use only
to_string and we (the github organization to which the project pertains) have a codebase providing both sorting algorithms (though less smart, hehe) and “number2string” functionality. So yes, thanks so much for the
fpm branch, it really brings a lot of value, even more for fast development and precise version management.
Overall I would not call HoneyTools a toy project, in the long run at least, but surely it has started this way. Hence I find Milan’s statement to be quite relevant:
(and I don’t think, in any way, this is a bad thing to happen…)
Coming to what probably is the more interesing part I would like to describe now what instead has not worked or, at least, has put me in trouble. Hopefully those pain points would gradually relieve…
First of all, as I said, the code is meant for aiding HPC computations and I felt quite a bit the “deployment struggle”:
stdlib_sorting module has some string related stuff that is using the
%im syntax and that does not compile with the processor we use for production on the HPC cluster: GCC 8.3.0 which, I know, is quite old indeed but, despite having a newer one available, it poses some trouble to correctly link with MKL and openMPI, so most people in the department is stuck with the older one.
Eventually I managed to get around the issue but it was an hassle and I think this sort of dynamics might well add to the general hesitance. The stdlib is modern in its very sould and unfortunately HPC environments are quite often unfriendly to modernity (just regular CentOS struggle…).
The other huge pain point is for sure the lack of modularity. The stdlib is divided in modules, sure, but they are somewhat interdependent and that forces a “all or nothing” feeling which often might resolve to “well, than nothing”. After my successful and overall pleasant experience I tried to push my “software head” (the researcher in charge of codebases) to adopt stdlib for more stuff, maybe even slowly replacing our “homebrew” stuff, but the main objection —a hard one— was exactly based on this module interdependence: he does not like the error handling implementation (for whatever reason) and as far as I understand you cannot really use a module without implicitly importing some
error_stop call inside the procedures (or at least you are not guaranteed to be able to… here an example). I think getting around the issue here is quite subtle: from one viewpoint I can totally see how the authors of some well thought error handling suite would like to adopt it in other parts of their wide project, surely composability is a great value and the whole point of a standard library, but I can also see how this forces to really “like” everything in stdlib (as it currently is) for choosing to adopt even a small part. In this embryonal stage I think the most likely outcome is people just discarding the library as a whole or at least postponing adoption until everything has clearly settled and there would no more room to argue.
So yes, this has been stressed a lot already, but I’d like to do it once more
I’ll end saying that despite these points I might add yet another stdlib dependency on HoneyTools, namely a hash map (preliminary details are here). Though I haven’t yet inspected the docs with enough care and I’m actually still evaluating some possible alternatives… the use case would be not so straightforward and flexibility would be key.
So yeah, surely
but the few that are seeing their first sun are quite interested in stdlib!