Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.programming Subject: Re: Informal discussion: comp.lang.rust? Date: Mon, 28 Jul 2025 22:18:49 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <1068t09$7a8$1@reader1.panix.com> References: <1067o6p$24rjd$2@dont-email.me> <106847g$33e$1@reader1.panix.com> <10686pv$24rjd$5@dont-email.me> Injection-Date: Mon, 28 Jul 2025 22:18:49 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="7496"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.programming:16817 In article <10686pv$24rjd$5@dont-email.me>, Julio Di Egidio wrote: >On 28/07/2025 17:16, Dan Cross wrote: >> In article <1067o6p$24rjd$2@dont-email.me>, >> Julio Di Egidio wrote: >>> On 28/07/2025 13:37, Dan Cross wrote: > >>> IOW, the idea that programmers in general need to be baby-seated >> >> I wouldn't phrase it as "babysitting". Rather, it's >> professionals making conscious choices about their tools to most >> effectively do their jobs. >> >>> instead of given control I find not just self-defeating but really >>> fallacious. >> >> In what way do you feel you have less control (and over what?) >> in Rust than in, say, C? > >To be clear, I have nothing against the institution of a >comp.lang.rust (on the contrary, I'd be tempted to say), nor >against the Rust language itself: Sure, that's fair. This is separate. >I am rather commenting on >some questions of principle, and maybe some marketing slogans, >especially on the themes of "safety" on a side and "assisted" >programming on the other. I'm not terribly interested in marketing slogans, to be honest. "Safety" in this case has a very well-defined meaning, which may not be the same as yours. As for "assisted", I'm not sure what that's about. Perhaps you mean the way that the language assists a programmer in writing more robust software? How is that any different than C assisting a programmer to write more robust software than straight assembly? Or assembly assisting to write more robust software than programming directly in machine code? >Indeed, I am not against a stratification of languages from lower >to higher level either, actually that's quite needed, I am just >of the idea that programmers should not be "protected" by anybody >but more competent programmers: but of course with that goes a >quite different idea of what *software development* means, and >to me it does not primarily mean we buy "solutions" at the shop, >the very opposite of that. The competence argument is ancient: as I alluded to above, when assemblers began to replace direct machine-language coding (often in octal!), being both less error prone and more expressive, they were decried as hopelessly inefficient (read: wasteful of very expensive computer time!) and their users simply lacking in some abstract definition of skill. When high-level languages began to emerge 70-ish years ago, and people noted that defect rates went down when programming them relative to assembler, many macro assembly language programmers made similar arguments, perhaps having forgotten that they themselves had been the object of that same criticism only a few short years before. Bluntly, the argument has never really held up in the face of actual evidence. The best C programmers in the world have written code with memory safety bugs: I've personally seen such bugs in programs written by the man who designed the language and implemented its first compilers. I've seen similar things from folks on the language standards committee. In other cases, programs have _appeared_ to work flawlessly for decades until a new point release of a compiler came out, and it turned out the program actually exhibited some kind of undefined behavior that the new compiler used to justify changing some crucial behavior in an unexpected way and the program "broke." If the best programmers in the world make these mistakes, then it's not a competence or skill issue. >Instead we get an inversion of the chain of control and of >responsibility that is rather one of the key ingredients, the >other being the denial of the very state of the art, of the >disaster that the whole industry has been made into across >the last ~30 years... > >...and the self-fulfilling prophecies, since average is the data, >averaging are and have been the policies, average are the results, >and the circle is closed: with the triumph of the levelling down >to ineptitude and consumeristic dependence. I started programming professionally about 30 years ago, and at the time, people were making the exact same arguments, about how the industry had been ruined over the previous 30 years, that we were spoiled by bitmapped graphics (what was wrong with a 80x24 VT-series terminal? Or even a teletype?), cheap RAM, cheaper disk, and ever-increasing CPU speeds, and how much we had lost by moving away from systems written by truly competent programmers in assembler, to high(er)-level languages that let you get away with not really understanding the machine, being inefficient, and that inevitably led to "toys" like Unix because people no longer had the discipline required to have any sort of idea what they were _actually_ doing. This was always a non-sequitor. The industry may be a disaster (I agree with that), but that doesn't mean that choosing to use a tool has better memory safety properties is a cause or symptom of that. Interestingly, with Rust, the language famously has a very steep learning curve (a former colleague once called it, "near vertical"), and is not known as a language for amateurs, so would seem to be a counter example against the kind of mediocrity you described. Similarly, one could make a strong case that arguing against memory safe langauges is a denial of the state of the art, which has largely moved on from e.g. C, C++, Java, COBOL, PL/I, RPG-2, Macro assemblers, and so on. Even Fortran is no longer really the state of the art for numerical programming. >Here is rather an analogy: go tell a race car driver that it is >"unsafe" for them to touch their breaks in a turn, and that you >actually have a "solution" in mind that will automatically disable >the breaks in a turn (and punish the driver for it)... or something >along that line. That's a bad analogy. A better one is the race car driver telling you that they don't need a 5-point restraint harness or flash-resistent outer suit because they already know how to drive and won't get into a wreck, and that those things are only for less competent drivers. And yet, just like we've seen the best programmers in the world introduce bugs in e.g. C code, we have seen the best racers in the world get into horrific crashes. The guy who tells you he doesn't need that stuff is going to end up dead in a crash that another, I would argue more competent, driver can walk away from precisely because competence means that the latter understands the value of and uses that kind of safety equipment correctly, without cutting corners. >Here is not an analogy: only a competent programmer knows the >discipline, the principles, the practices, and in fact how to >organise not only a production unit that delivers excellent >products, but also that continually grows in the level of >competence and professionalism, with clear paths for learning >and action since the beginner stages. Those programmers also understand the value of defense in depth, and of chosing tools that optimize their ability to deliver value in the form of performant and correct programs, produced in a reasonable amount of time. Such programmers devote considerable time to professional development, learning and adopting new practices and tools when that makes sense, and shedding older practices and tools when that makes sense. A mark of professionalism is understanding the tradeoffs involved and making wise choices. The field is not stagnant, and while it may suck generally, that does not mean that that chosing to use a safer tool is an admission of incompetence. There was a generation of programmers who produced application software in macro assembler langauges on machines from the IBM System/360 to the DEC VAX to the Data General Nova. Hands down, the _best_ programmer I've ever met in my life's favorite language was PDP-10 assembly. But there's a reason we don't write new systems in assembler anymore, and it's not a skill or competence issue: it's because we get better software from higher-level tools. >Because software engineering is the most complex engineering >that there is: it takes some 10 years to those who are really >committed to start understanding what it is actually about, >and some another 10 years of at least as much commitment to >become real pros. I'd say that's more a reflection on the overall immaturity of the field. Human beings have been building bridges over rivers for thousands of years; it wasn't until the 19th century that we started to actually get good at it. We've been programming computers for less than 100, and we're still at the "chop down a tree so it falls over the narrow part" stage. We also hold ourselves back because, when someone comes up and says, "hey, have you heard about this reinforced concrete thing? It's more durable and can support a lot more weight..." our response is too often, "what's wong with wood? If you were more efficient you wouldn't _need_ to support all that weight." - Dan C.