by stackghost 11 hours ago
I've always had a soft spot for Fortran, even though I rarely use it any more.
When I was in undergrad, so sometime around 2006 or so, I read somewhere that Fortran was actually faster than C in some cases, due I believe to the compiler and certain choices it makes regarding aliasing arrays and whatnot.
I am an aerospace engineer and avid flight simmer, mostly WWII combat sims, and a huge part of the hobby involves arguing with other people about WWII piston aircraft and their performance. Pages upon pages of forum threads replete with PDFs of historical documents in German, Russian, etc. In order to win arguments more effectively, I decided to write a parametric "flight sim" that would accept a set of maneuvers as an input (e.g. "start at 10000m, dive until speed reaches X km/h indicated, zoom climb back up" or "turn in a circle at Y km/h indicated") so that I had something to compare the in-game results and historical data with.
I decided to write the whole thing in Fortran 2003 (the 2008 revision was still a draft, as I recall), because fast.
I bought a copy of Stanley Hooker's book "The Performance of a Supercharged Aero Engine" from the Rolls-Royce heritage press, implemented the method therein. Implemented a numerical vortex panel method for the lifting surfaces, the whole shebang. It was actually a really fun project and it worked pretty well. Fortran is a neat, quaint language and I look back on that project fondly but ultimately I don't miss Fortran. The syntax is needlessly verbose. I/O is a chore. String manipulation is a pain. If you ask me, C++ (despite its many flaws) is superior in every way.
Author of LFortran here. LFortran is written in C++, because I knew I will be able to fully deliver the project in it. So I know C++ and Fortran very well. I can say for sure that C++ is not superior in every way. It's slower to compile, hard to deal with dependencies (that's more of a tooling issue), it's more complex, and specifically for numerical array-oriented computing C++ is actually much more verbose and harder to read. For non-numerical computing, such as compiler development, C++ is not a bad choice, that's why I chose it. The slow compilation of C++ is truly a major problem for me, and after we deliver LFortran we'll see if maybe moving to C might be worth it, just to get 10x faster compilation of the C/C++ sources of LFortran itself (the speed of LFortran I think would be similar, we already use arenas and other tricks for performance, which can be done in C just as easily).
I will concede that compile times in C++ do indeed suck.
But surely managing dependencies with e.g. vcpkg is no worse than with fpm?
I haven't used vcpkg, but looking at their tutorial at https://learn.microsoft.com/en-us/vcpkg/get_started/get-star..., it seems you still have to use cmake, and if so, it is indeed more complex than fpm (https://fpm.fortran-lang.org/tutorial/hello-fpm.html) where you don't use cmake. Fpm is similar to Cargo. Cargo is indeed as simple as fpm. However, as I mentioned above, this is just a tooling issue, somebody can (and should!) write Cargo for C++. In fact, fpm can build C++ projects also.
The best package manager that I like the most for C++ is Pixi (https://pixi.prefix.dev), that works really well.
FORmula TRANslation, the clue is in the name. It's great at math, but yeah, strings and OS stuff is a PITA. The modern vector-based syntax is still really nice and I've yet to come across a C++ library quite as slick.
But I think what it was really missing last time I looked at it was good access to compiler intrinsics (or otherwise) to hit vectorizations and math optimization instructions. The OpenMP simd pragmas weren't really doing a fantastic job. I hope that's better now it's in LLVM.