Also, while I'm sure you don't intend it this way, simply listing the issues like that is a bit visually deceptive in that our hindbrains tend to assume all those issues are roughly equally weighted, because they're all roughly equally the same size. But the distribution of issues there is very non-linear. C doesn't just have a bit of an issue with undefined behavior; it is nearly (but not quite) uniquely damaged by it.
Hypothetically some type systems could partially cover some of the things you've labelled as "no", but I'll aggressively beat you to the punch that such things are very hypothetical, except I'll be saying it with sadness and through grinding teeth, because I find it frustrating how thoroughly our environments ignore some issues like that. But that's a rant for a century I don't expect to live to see.
My point is, if you're not putting that much effort into your codebase -- whatever the language you're not getting those results. There is no language that makes developing and maintaining SQLLite easy or straightforward.
I'd agree with you, except that just this morning I was reading a paper about the NARCISSUS framework that can automatically generate encoders and decoders that provably conform to a given specification, and can be extended by a user without rewriting or modifying the framework itself. The authors even patched a networking stack (in MirageOS) with the not-especially-optimized ML extracted from their generated code and showed a performance hit that could be considered acceptable for real-life use cases.
https://www.cs.purdue.edu/homes/bendy/Narcissus/
With advances like this in program synthesis and formal verification, plus real progress in machine learning, it feels like we're living in the start of the age that was _supposed_ to happen during the golden age of AI.
(Excuse the gushing hyperbole. My coffee must have been stronger than usual this morning.)
You did more than that: you've suggested that C was only usable if a pile of safety infrastructure by providing sqlite as your proof, and once that claim was debunked you kept insisting on your baseless assertion.
> I'm just saying that you can't use SQLite as proof that C is A-OK okey dokey
There is no need to prove that because it's quite obvious that C is fine. If you feel the need to prove otherwise then you need to put forward your own proof. Either you support your baseless assertions with rational and tangible claims or you're just venting an irrational dislike. Meanwhile the world runs on C and has been running for decades.
> it's OK to just keep programming in it forever, because it does not use C. If you're not putting in that much effort to your C codebase, then you're not getting those results.
You're somehow turning a blind eye to the fact that that "effort" is patently language-independent and has absolutely nothing to do with C. Either you somehow missed the whole point of the post or for some reason felt the need to keep repeating baseless claims that were already debunked.
I have no idea why you've developed an irrational hatred of C, but it clearly is a personal issue, not a technical one.
No. It is quite obvious to anyone rational and without a vested interest that C is no longer fit for purpose in this modern age.
> I have no idea why you've developed an irrational hatred of C
Let me guess. He's sick of patching security holes, memory leaks and crashes?
Look at the types tests listed in the executive summary... which of these can be obviated by language features?
I'll try to break it down:
* Out-of-memory tests: no, all languages run out of memory. The explicit nature of memory management in C might help here, since there's no mystery about exactly where the failure might occur.
* I/O error tests: no, IO failures are independent of language.
* Crash and power loss tests: no, this has nothing to do with language.
* Fuzz tests: yes, partially. Different languages can reduce the range of invalid input a program could encounter.
* Boundary value tests: yes, partially.
* Disabled optimization tests: no, the optimizations being referred to here is a feature of SQLLite, which would need to be tested, regardless of language.
* Regression tests: no, this is independent of language.
* Malformed database tests: partially, because some languages are better at validating input statically, which covers some of the cases of malformed databases.
* Extensive use of assert() and run-time checks: I say no. Yes, asserts are code you need to write, and a cognitive load. But navigating the built-in language constraints of more type- and value- validating languages are also a cognitive load. I believe asserts are often a lessor load since they can be in the problem space of the software being developed vs. the problem space of the language design. In C the molehill comes to the mountain. OK, Ok, on the other hand, in C no one forces you to write good asserts. But then, in no language does anyone force you to write code that actually does the job.
* Valingrad analysis: yes
* Undefined behavior checks: yes
So, largely no. Other languages solve some problems, yet have their own drawbacks.
You're drawing a sharp distinction between "C" and "C with analysis backing", yet there is no such distinction in the real world. We see in this project what we would see in every successful, long-running project (and do NOT see, 100%, in every project that failed in the long-run): controls in place to deal with the potential pitfalls. One advantage to C is that it's history can give you some nice guidelines to understand when you have pretty good coverage on those, from a language standpoint.
I mean, I'm not arguing that some modern languages have their advantages. But, they have disadvantages as well. And, their advantages -- restricted as they are to static analysis -- solve little problems, not the bigs ones.