I understand what you're saying, but I want to do whatever I can to promote the shift in attitudes that's already happening across the industry.
And being late or never delivering out of fear of shipping buggy code is even worse.
From a business perspective, yes, usually true. But shipping buggy software can also harm your company's reputation. I doubt that this has been researched enough yet to be quantifiable, but it's easy to think of companies who were well known for shipping bugs (Microsoft, CD Projekt Red) and eventually suffered in one way or another for it. In both of those cases, you're probably right; Windows was good enough in the 90s to dominate the desktop market, and Cyberpunk 2077 was enough of a technical marvel (for those who had the hardware to experience it) that it probably bolstered the studio's reputation more than harmed it. But could Microsoft have weathered the transition to mobile OSes better if it hadn't left so many consumers yearning for more reliable software? And is Microsoft not partly to blame for the general public just expecting computers to be generally flaky and unreliable?
Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn't that be a better state of things overall?
I care about types not just because I like having stronger confidence in my own software, but because, as a user, bugs are really annoying, and yes, I'm confident that stronger type systems could have caught bugs I've seen in the wild as a user.
You're not wrong, but not everything needs to scale to 200+ servers (...arguably almost nothing does), and I've actually seen middle managers assume that a product needs that kind of scale when in fact the product was fundamentally not targeting a large enough market for that.
Similarly, not everything needs certifications, but of course if you do need them there's absolutely no getting around it.
But how does the alternative solutions compare with regards to maintainability?
Which alternative solutions are you thinking of, and have you tried them?
Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?
For what it's worth, WSL 2 with VSCode is actually great. Almost all the benefits of Linux (I still miss true tiling window management), with fewer weird driver issues.
That said, I generally just use whatever my company wants me to use, and I haven't worked somewhere that let us use native Linux boxes since 2014.
Rust feels like entirely the wrong target for that sort of criticism, especially regarding "energy and resource intensity". Rust is well-known to be comparable to C in its efficiency.
I haven't told you to keep calm. I'm just confused about you repeating the same points, in the same words, over and over, even after being told that you don't have your facts correct.
I'm not saying you can't learn or talk about other languages; I'm confused by the mismatch between your posts criticizing people for promoting newer tech stacks and the ones where you seem to be promoting newer tech stacks yourself.
25 years of experience is certainly enough to have strong opinions, but until your last comment I had the impression that you had a year or less of experience in C, hence my question.
Why do you keep posting the same rant about "going back to the roots", especially after multiple people have pointed out that C is not "the roots" of programming?
Why do you have such strong opinions about a language that you're still learning?
If you're that passionate about C and believe that people should use it instead of newer languages, why do you care about Nim or Nelua?
Doesn't prolog already "not work half the time"? (Disclaimer: I haven't used it.)