[rauhl]

> Can you really blame the whole world for misusing a tool, without taking a critical look at the tool itself?

I’m reminded of all the folks who — in 2018! — try to claim that C is a perfectly good tool for writing large, secure systems. Never mind that it loads a gun, puts it in your hand, cocks the hammer, points it at your foot, puts your finger on the trigger, and pulls back just to the release: the fault is really only yours if you shoot your foot — or so these folks say.

[Jtsummers]

The problem of C is the success of C. There have been some good, secure, large codebases written in it. Some truly beautiful code, when you scrutinize it.

This creates the illusion that the language itself may be safe, if only you do everything right. That last part is often forgotten by the time people make the decision to write something large in it.

There is no problem with safety nets. Good debuggers (extreme ones like Common Lisp, allowing you to rewrite broken code on the fly and resume from that spot). Good type systems (Ada, the MLs, going so far as to eliminate most errors regarding common mistakes like array-out-of-bound exceptions). Good test suites (comprehensive unit and regression test suites, fuzz testers) which are, admittedly, more pervasive across many languages (the option is available, at least). Formal methods (even the lighter weight ones, like design-by-contract). Automation, to minimize the impact of human error and fat-fingering things. There should be no concern about choosing a language which is semantically closer to your problem domain, but perhaps of slightly reduced performance, than a language that is semantically distant (see people writing half of Prolog into their complex code base involving knowledge bases and decision trees). Maybe some people will think you're not tough enough, but at least your code doesn't piss off every user.

We cannot trust ourselves to do the right thing at all times. Consequently we must decide on the language and environmental elements which can enforce the right thing, while minimizing the impact to developing our solutions in a reasonable amount of time.

[xenadu02]

> There have been some good, secure, large codebases written in it

Citation needed. The only one I'm aware of is SQLite, which has an order-of-magnitude more test code than implementation code and still fuzzers are able to find new memory safety bugs in it.

[eikenberry]

Almost anything by Dan Bernstein might make a good example.

[ergothus]

JS bloat and abuse is very, very real - but the issue isn't JS itself but that the ASKS are bloat and abuse. In contrast with your example, the tool (C) is a bad choice for the job (secure systems). For Web, change the ask and the tool selection may very well change.

I'm a web dev since the 90s, and a JS dev for the last several years. I didn't start in JS, and when I'm asked to do different things I will move away from JS without a major fuss. I use it not because JS is my religious zealotry (though I'm not part of the "cool kids hate JS" club by any measure) but because JS is the least painful way to do what I'm being asked to do. Change what you ask, and I'll change my tool selection.

From this perspective, I don't find your example paralleling the situations to be highly applicable.

[philwelch]

C is more like operating a very large saw without a handguard. If you're skilled and you know what you're doing, you won't cut off your fingers. Which means the median developer cuts off his fingers.

JS (and, more to the point, heavyweight JS framework code) is more like driving a massive SUV around everywhere because you think having to drive through snow and mud is more likely than having to park downtown, when really, all you do is drive around downtown in the summer. But you don't care, because you have a parking valet.

[pjmlp]

We all know how scrutinized Linux and BSD kernel development is and yet CVEs due to memory corruption happen all the time, to the point Kernel safety was the major topic all Linux Security Summit 2018.

If the best aren't able to write safe C what to say about everyone else?

[philwelch]

I wouldn't use a power saw without a handguard, either. But I'm not gonna tell Linus the master carpenter that he can't use his antiquated power saw. Sure, he only has eight fingertips, but he also built the tower we're all standing on right now and continues working on it to this day, so if he's really doing something wrong, the only way to prove it is for someone to get a newfangled power saw, with handguards, and build their own tower. And maybe, someday, someone will do that, and we will look back on the days of poor old Linus and his seven fingertips and wonder.

[Volt]

I don't know of a single person who hasn't made very bad mistakes using C. Even the stuff coming from Bell Labs (Plan 9, UNIX) has had trivially avoidable bugs. By your analogy, everyone has lost at least one digit.