I was also dumbfounded by this claim. The only thing I could think of were C++ monomorphic templates that will avoid the penalty of some indirection and DIY dynamic typing.
Is it outrageous because "performant" is kind of a vague term. Does it mean... Fast? GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? For what kind of applications?
Modern Fortran has a lot to offer for scientific and numeric computation - easier to learn than C++, and easier to optimize in many cases. Scales from small systems to supercomputers, and there is even CUDA Fortran.
Nobody uses "performant" to refer to any of those. It usually means either high throughput, or some aggregate of high throughput + low latency + low memory usage.
Thanks for the response - from my perspective the most meaningful measurement of "performance" (basically "efficiency" but also throughput) is computation per unit of energy (and heat which has to be dissipated), but memory efficiency is also important, as is tail latency in certain cases.
What does "Rust is roughly as performant as C" mean, do you think?
I think they may be talking about math algorithm heavy code, where C++'s looser almost-just-a-substitution generics system (really "templates" not even quite generics) can be used to create abstractions that compile everything down to inlined maximally performant code.
This type of code tends to be hard to maintain though.
AFAIK you can get there in Rust but it's a little more cumbersome. You have to implement a lot of operators, and for that type of code you might actually benefit from #[inline(always)] which is discouraged in normal Rust.
I think they're all ideas that are relatively obvious intuitive responses to the problem, and yet they may only incrase complexity tbh. For example, constexpr can be used relatively independent of template programming even, yet where they can be used practically before it becomes an unmaintainable mess of boilerplate are the most trivial cases, almost those which you could have hacked in with macros. TBF I think if you need serious metaprogramming, just compile and run a program at compile time.
Reflection has always been a mess no matter which implementation or language I've used. Fine for scripting languages, unusable for anything serious complex. The data you need is never there, and the data that is there is unusable, at the wrong semantic level (programming language level not what actually your own domain model semantics).
Also I avoid templates for the same reason, they're quickly becoming unmaintainable. Yes, I've tried to make use of them many times, and I have a fair number of them in deployed software. They work without bugs, of course. But I still don't love them, they're boilerplatey hard to maintain complexity that would be better solved with the right factoring plus a tiny bit of ad-hoc boilerplate. I would like to remove many of my deployed templates if I had the time.
And yes, I even avoid std:: template containers and such. Most uses I regret later. Again, this is for systems programming. They're fine for "scripting", leetcode, business software.
Is writing compilers, linkers, database servers, HPC and HFT platforms, OS drivers, networking stacks at IP level, considered systems programming accordign to you, or are they plain business software?
I said, I avoid, I don't love, I was talking about preference. And I'll state: Most of these are written mostly like I say. Please find serious counter-examples.
You must be talking about Linux, the BSDs, sqlite, postgres, gcc, the mold linker, or let's take some new kids on the block: raddebugger, FilePilot, TaskSlinger?
I am for example talking about LLVM and GCC, used to compile all those examples.
Living in the past? GCC has long adopted C++, last time it compiled with a pure C compiler was back in 2011 thereabouts, not cross-checking the exact year.
Actually care to open GCC and see what I mean? Check the newest commits and see what they do. Maybe you're living in a dream world where some magic language features do the work for you. Meanwhile people out in the field do actual work by just pushing bytes at the low level.
> Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support for used C++14 features.
> Versions of GCC prior to 15 allow bootstrapping with an ISO C++11 compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98 compiler, and versions prior to 4.8 allow bootstrapping with an ISO C89 compiler.
> If you need to build an intermediate version of GCC in order to bootstrap current GCC, consider GCC 9.5: it can build the current D compiler, and was also the version that declared C++17 support stable.
Why are you unable to get my point? I understand that GCC doesn't compile with plain C compiler anymore. A lot of my own code doesn't!
I'm saying that most of features like templates, constexpr, reflection etc. don't scale well to serious use, as a broad statement. I fully acknowledge this is not a black and white situation. But I encourage you to look at actual pedestrian code, it's mostly not abstracted fluffy magic template code at all. It's pushing individual bytes with totally basic means (mostly C code). Why? Because code using these fluffy features is terribly hard to maintain. Templates lock you in their own language world with incredibly bad syntax and bad ergonomics, in short: it's a pain!
Personally I think even C++ classes (i.e. 1980's C++) are unusable because they bifurcate syntax/semantics needlessly and add implicit invisible scope. But I acknowledge it's somewhat possible to program with classes, and some people like to lean on RAII heavily. I mostly do not like to use RAII, and I've tried many times, I think it sucks for non-toy programming, even though obviously the idea is intuitive.
Please provide proof for this outrageous statement.