Groups | Search | Server Info | Login | Register

Groups > comp.programming > #16817

Re: Informal discussion: comp.lang.rust?

Show all headers | View raw

In article <10686pv$24rjd$5@dont-email.me>,
Julio Di Egidio  <julio@diegidio.name> wrote:
>On 28/07/2025 17:16, Dan Cross wrote:
>> In article <1067o6p$24rjd$2@dont-email.me>,
>> Julio Di Egidio  <julio@diegidio.name> wrote:
>>> On 28/07/2025 13:37, Dan Cross wrote:
><snip>
>>> 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.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 07:46 -0400
  Re: Informal discussion: comp.lang.rust? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-10 07:14 -0700
    Re: Informal discussion: comp.lang.rust? Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-10 16:42 +0000
      Re: Informal discussion: comp.lang.rust? c186282 <c186282@nnada.net> - 2025-06-18 02:51 -0400
        Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 11:37 +0000
          Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-28 13:50 +0200
            Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 15:16 +0000
              Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-28 17:59 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-28 22:18 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 10:18 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 12:16 +0000
                Re: Informal discussion: comp.lang.rust? David Brown <david.brown@hesbynett.no> - 2025-07-29 17:37 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 18:24 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-29 19:14 +0200
                Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 18:27 +0000
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) David Brown <david.brown@hesbynett.no> - 2025-08-02 17:47 +0200
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-04 22:33 +0000
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) David Brown <david.brown@hesbynett.no> - 2025-08-06 18:38 +0200
                Re: Rust vs Hype (was Re: Informal discussion: comp.lang.rust?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 03:30 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 19:08 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:00 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 20:34 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:40 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-07-30 20:51 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:53 +0000
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-09-05 10:59 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-08-03 17:55 +0200
                Re: Informal discussion: comp.lang.rust? Julio Di Egidio <julio@diegidio.name> - 2025-08-03 18:17 +0200
              Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-29 06:24 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-29 12:27 +0000
                Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-30 07:44 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 11:30 +0000
                Re: Informal discussion: comp.lang.rust? Richard Heathfield <rjh@cpax.org.uk> - 2025-07-30 16:51 +0100
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-07-30 18:00 +0000
                Re: Informal discussion: comp.lang.rust? David Brown <david.brown@hesbynett.no> - 2025-08-02 18:41 +0200
                Re: Informal discussion: comp.lang.rust? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-04 22:34 +0000
  Re: Informal discussion: comp.lang.rust? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-10 17:35 -0400

csiph-web