Frankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"
No, it just showed that the person who made that argument has actually used C very little, not even in the sense of reading other's code. For anyone working with C (hence being able to make an informed statement about its suitability) that piece of code would immediately strike as "not C".
It's an important distinction when someone "proves" C is shit by using a very short example of just a few lines, which
obviously isn't C, claiming it "of course" goes through a compiler, which it
obviously doesn't:
hrst@jorma ~ $ gcc test.c
test.c: In function ‘main’:
test.c:6:5: error: unknown type name ‘boolean’
boolean myFlag;
^
test.c:9:12: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
myFlag = "A";
If they had thought this over, the example would make the point. Now it's a piece of code which is neither C, nor showing any meaningful point even if corrected to be C. If anything, it demonstrates type safety on any compiler I tried (different clang and gcc versions; no extra flags necessary) by issuing warnings about the strange type conversions performed by the programmer (and hence, suggesting more explicit proof, in form of explicit cast, that the assignment is intentional.) Many modern languages would accept the equivalent series of statements, not only without any warnings, but performing "something probably useful", and worst, this would not be an example how
not to do it, but an example
how to do it.
All in all, even if adjusted to go through compiler, the example showing the implicit type conversions of the boolean type is funny in this context, because compared to most modern contenders (such as Python), C is
more strongly typed, and from this viewpoint,
more safe. If they wanted to show an example of C being unsafe, out-of-bounds indexing, or missing a zero termination on a string, would be classics, or using one of the many dangerous classic C standard library functions (such as sprintf) people still use out of convention.
The general direction seems to be: implement less and less type enforcement, and do more and more silent type conversion,
for convenience, for beginners. Which, obviously, is
dangerous even if it is convenient. Operations don't make sense when you don't know what the operands represent, and when the representation suddenly changes between adjacent operations.
But it's always trendy - have been for dedaces - to circle jerk around C's extreme level of dangerousness, and claim that modern alternatives are magically much more safer. This is naturally not the complete picture. C indeed lacks many "safety features", and has some dangerous design choices, but strict(er) typing (compared to most trending languages, that is), which is optionally bypassable with clear and explicit syntax, seems quite a good mix between safety and performance. It could be better, even in C you have implicit type conversions happening when you least expect it, allowing for a footgun of a sort, but it's still a lot better than having no type enforcement at all. (It always strikes me funny how people who show C isn't type-safe enough, offer the solution of removing type-safety completely.)
C has never been academically trendy because it isn't pure, all sides of it lack something. Yet it seems to be "good enough", and the contenders come and go, struggling, often trying to be too pedantic and losing the big picture.
Python's typing is
handy, just type some letters from the keyboard without thinking, and it
guesses the intent, and does fairly good job on it: when you test the code, it
likely does what you wanted. For safety, relying on such luck element is an utter catastrophe (especially when the runtime can change its decision with a different version). The fact that a
type is not only dependent on the code, but also the runtime data content (I remember struggling with this with PHP in 2002), is a safety disaster and it's very hard to get 100% test coverage.
That's why Python isn't used for mission-critical embedded work, but C is, despite its undeniable shortcomings, even regarding safety.