This really does depend on how "reliable" is defined. At the code level, reliable is dependent on the actual programmer. This code must then be compiled/interpreted in order to to actually function. At this stage the programmer has lost control unless they are also in direct control of the interpreter/compiler - which is, of course, impractical and extremely unlikely.

Inevitably writing in high level languages sacrifices control for how the program looks at the machine level simply because you must depend on existing structures. The higher up you go, the less control you have of the final product. Writing in Python vs. C means that you have to think less about lower level issues and consequently are subject to problems that arise outside the scope of what you could have originally controlled - simply because you didn't have to think about a subclass of issues that you assumed were inherently solved for you.

So yes - if you take a Python program and rewrite it in C, you can get a more reliable program IF you properly solved the set of things that Python took care of for you in relation to your specific problem.

But this relies on the fact that you succeeded in rewriting what Python took care of for you. So we're back to where we started - it all depends on the programmer.

The article implies this in the final sentence:

All that said, I don't recommend using C unless much thought has been given to the decision - the resulting software might be reliable, but it will have taken a significant human effort to produce it.

And this basically negates that C is any more reliable than whatever other programming language. Despite the fact that I think a discussion of reliability of a language is effectively useless (at least the way I've framed it here, I'm open to other interpretations), I enjoyed the article - thanks for sharing!

How does effort affect reliability? Even if you consider one as consequence of the other ("it requires more effort to make a reliable C program than the equivalent program in $language") that doesn't make the final product any less reliable.

it is more about the attitude of a C programmer versus the attitude of a, say, JavaScript or Ruby programmer. Whilest the latter merely assumes "nah, the VM will catch all null pointers as soft exceptions for me, and all exceptions I don't catch, my caller should." the first kind of programmer has learned (the hard way) to respect as much of the error codes a function call can return. "The hard way" is the malicious smiled SIGSEGV dynamic-programming language programmers may laughter about, because it hardly crashes your program, one may say.

However, I do believe, that this attitude to think first (how to program right) rather than trying to remember (what could have caused that many 500's on my HTTP server) which I think is the better approach to write more reliable software.

Dynamic languages are said to be more convenient for web sites, for example, I'm not denying that one, but those languages just shift the problems back into the future, where, when time has come, you may or may not be willing to attempt to fix the bug you introduced days/weeks/months ago, depending on the urgency.

On programming environments (such as C), where types are more statically typed, errors have to be handled manually and with caution, memory has to be managed (more or less) always with an ownership in mind, those programs, that think about these topics from the very beginning, and iron out those remaining bugs over time, are - from my point of view - the more reliable ones.

So I can out of my distance second this blog post. It was interesting to read.

It does when you only have a set amount of effort that you can dedicate on a project. Which is usually the case.

I am not sure that's a useful criterion in practice, though. People are fond of saying that languages will not make you orders of magnitude more productive, and I think the corollary is that on average they will not make you orders of magnitude less productive either. (Controlling of course for characteristics of problems and such.)

The problem is that there's not really a great way to reason about this, either. If you're talking about how long it takes to write a program in C vs Java, how do you measure time spent writing code vs debugging vs bug fixing, et al?

All in all it's certainly possible it takes longer to write code in C, but for all anyone knows, writing more reliable code up front means fewer bugs later on. Code which is more performant by default may lead to fewer performance regressions when someone induces pathological GC behavior. Contrariwise, there's stuff like memory corruption as the OP describes, which is probably way more difficult in a native environment instead of a hosted one.

It's hard not to reach the conclusion that we're all just talking out of our hats anyway (myself included).