Ye I feel the author has no clue what he is talking about.
"I can appreciate the “macho factor” of being able to write fast software in C or C++ (or even Objective-C), but most people aren’t going to be able to do that"
I mean, C is probably the simplest tool to write fast software with, since there are so few hidden costs to know about. Like strdup does a malloc. What else?
In C++ you have to know implementation details of the standard lib and calling conventions to write fast code. Java, C# and Go the same but abit more.
For e.g. Haskell and Julia you need to know quite much to reason about what code will be generated and good luck doing that with complex code.
I did not mean it is 'simple' to write fast C code, but that it is 'simpler'.
Simpler in the amount of knowledge you need to have to write the fast program.
I mean just compare "C the programming language" with Stroustrup's "C++ the programming language". It took me years to understand even a fundamental thing as move semantics. When programming fast C++ you need to be able to see what is moved properly and optimized in the way you want. How classes are inlined into the code etc. What container do malloc on construction, what containers are cheap empty, and so on and on.
> You can write reasonably fast software in almost any decent language (with a few exceptions). But in order to do so, you have to have some idea of how to design and write software in mechanical sympathy with your surroundings.
Looking at the whole statement I think that the argument is that algorithms are more important than language when it comes to speed which is correct (with a few exceptions).
What the software actually attempts to do probably also matters a lot for what "reasonably fast" is. Would i write a distributed file system, a web server, or a database engine, or some OS component in pure Python? Probably not (assuming CPython, something like PyPy might make it more viable). But at the same time, Go might be a decent option for any/all of those, despite generally being a bit slower than C/C++/Rust.
That said, Python, Lua or anything else that's often touted as a decent language despite being on the slower side could be a good choice for glue code (just look at machine learning, number crunching and other domains where Python is pretty common), maybe creating various scripts (e.g. for setup/automation of common tasks without having to do everything in Bash), or maybe developing CLIs/TUIs or libraries to act as front ends for more complex bits of other software.
What probably also matters a lot for system software is C interop, or just how well the software can integrate with the system libraries etc., unless we're talking about something that's fully statically linked. Of course, this doesn't necessarily have that much to do with speed, just another factor to consider.
Also, while on the topic of other things that matter, the speed of development is also one such thing - not everyone has excellent knowledge of the intricacies of working with lower level languages and frameworks for them. Surely system software shouldn't necessarily be restricted to a select few developers, so anything with fewer footguns could be worthy of consideration!
In short, use whatever works for you, but "reasonably fast software" isn't all too restrictive of a target so in the modern day most languages can indeed find their place in the grand scheme of things. There's very little preventing you from writing most of your software in Python and writing the 10% of performance intensive code in something else.
Of course, limitations apply - for example, writing GUI software with Electron will usually be done for ease of development rather than performance (just look at how much resources Microsoft allots to getting Visual Studio Code to perform well vs something like Brackets/Atom which are really sluggish in comparison). Admittedly, GUI software isn't always the first thing that people think of when talking about "system software", but i feel like that disclaimer is a must anyways, there's lots of nuance to everything out there.
From what you wrote, it appears you don't know the meaning of "reasonably", "decent", "exception" and that you set your mind to disagreeing with the author before even fully comprehending the post.
"I can appreciate the “macho factor” of being able to write fast software in C or C++ (or even Objective-C), but most people aren’t going to be able to do that"
I mean, C is probably the simplest tool to write fast software with, since there are so few hidden costs to know about. Like strdup does a malloc. What else?
In C++ you have to know implementation details of the standard lib and calling conventions to write fast code. Java, C# and Go the same but abit more.
For e.g. Haskell and Julia you need to know quite much to reason about what code will be generated and good luck doing that with complex code.