Behold: [fformat](https://github.com/jacobwilliams/fformat) – A Fortran formatter written in Fortran. Another vibe-coded experiment, using Claude Opus 5.5, to create a quite useful tool that would not traditionally be written in Fortran. The results are just amazing.
Here is a speed test using [fortranpack](https://github.com/jacobwilliams/fortranpack) (38 libraries, 276 files, 183,666 lines of code):
| Tool | Written in | Version | Time (s) | Lines/s | Relative time |
|---|---|---|---|---|---|
| fformat | Fortran | 0.1.0 | 0.555 | 330,667 | 1.0x |
| [fprettier](https://github.com/fredjones42/fprettier) | Rust | 0.5.0 | 0.701 | 261,840 | 1.3x |
| [fprettify](https://github.com/fortran-lang/fprettify) | Python | 0.3.7 | 20.978 | 8,755 | 37.8x |
Obviously, there are some disclaimers here (the different tools maybe aren’t quite doing the same thing, etc. I can try and update the test to try and use consistent settings for each as best that can be achieved). But as a first cut, this is amazing! The Fortran version is slightly faster than Rust, and of course the Python one is incredibly slow.
Honestly, what is the advantage any more of using Python for tools like this? Why would anyone choose a slower tool over a faster one that does the same thing? A Fortran formatter doesn’t need to be dynamic in any way. The “batteries included” argument for Python also is almost irrelevant now. I’m using a couple of existing Fortran packages via FPM, and for this project also created a brand new regex library on top of that (see fregex). And why introduce a newfangled esoteric programming language like Rust when it’s not even faster and we can do everything we need in good ole Fortran? (Don’t come after me Rust bros!)
This is all very preliminary and experimental. I’ve spent almost no time on this at all. But it seems like really getting this up to production use wouldn’t take that much effort.