The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <>
To: Ed Carp <>
Cc: COFF <>
Subject: Re: [TUHS] more about Brian...
Date: Sun, 6 Feb 2022 09:13:56 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

Oh dear. This is getting a little heated. TUHS to Bcc:, replies to COFF.

On Sun, Feb 6, 2022 at 8:15 AM Ed Carp <> wrote:

> Since you made this personal and called me out specifically, I will
> respond:
> "In what way is automatic memory management harder, more unsafe, and
> less robust than hand-written memory management using malloc and
> free?"
> Because there's no difference in the two. Someone had to write the
> "automatic memory management", right?

I cannot agree with this, there is a big difference.

With GC, you are funneling all of the fiddly bits of dealing with memory
management through a runtime that is written by a very small pool of people
who are intimately familiar with the language, the runtime, the compilation
environment, and so on. That group of subject matter experts produce a
system that is tested by every application (much like the _implementation_
of malloc/free itself, which is not usually reproduced by every programmer
who _uses_ malloc/free).

It's like in "pure" functional languages such as Haskell, where everything
is immutable: that doesn't mean that registers don't change values, or that
memory cells don't get updated, or that IO doesn't happen, or the clock
doesn't tick. Rather, it means that the programmer makes a tradeoff where
they cede control over those things to the compiler and a runtime written
by a constrained set of contributors, in exchange for guarantees those
things make about the behavior of the program.

With manual malloc/free, one smears responsibility for getting it right
across every program that does dynamic memory management. Some get it
right; many do not.

In many ways, the difference between automatic and manual memory management
is like the difference between programming in assembler and programming in
a high-level language. People have written reliable, robust assembler for
decades (look at the airline industry), but few people would choose to do
so today; why? Because it's tedious and life is too short as it is.
Further, the probability of error is greater than in a high-level language;
why tempt fate?

> "This discussion should probably go to COFF, or perhaps I should just
> leave the list. I am starting to feel uncomfortable here. Too much
> swagger."
> I read through the thread. Just because people don't agree with each
> other doesn't equate to "swagger". I've seen little evidence of
> anything other than reasoned analysis and rational, respectful
> discussion. Was there any sort of personal attacks that I missed?

It is very difficult, in a forum like this, to divine intent. I know for a
fact that I've written things to this list that were interpreted very
differently than I meant them.

That said, there has definitely been an air that those who do not master
manual memory management are just being lazy and that "new" programmers are
unskilled. Asserting that this language or that is "ours" due to its
authors while that is "theirs" or belongs solely to some corporate sponsor
is a bit much. The reality is that languages and operating systems and
hardware evolve over time, and a lot of the practices we took for granted
10 years ago deserve reexamination in the light of new context. There's
nothing _wrong_ with that, even if it may be uncomfortable (I know it is
for me).

The fact of the matter is, code written with malloc/free, if written
> carefully, will run for *years*. There are Linux boxes that have been
> running for literally years without being rebooted, and mainframes and
> miniframes that get booted only when a piece of hardware fails.

That there exist C programs that have run for many years without faults is
indisputable. Empirically, people _can_ write reliable C programs, but it
is often harder than it seems to do so, particularly since the language
standard gives so much latitude for implementations to change semantics in
surprising ways over time. Just in the past couple of weeks a flaw was
revealed in some Linux daemon that allowed privilege escalation to
root...due to improper memory management. That flaw had been in production
for _12 years_. Sadly, this is not an isolated incident.

That said, does manual memory management have a place in modern computing?
Of course it does, as you rightly point out. So does assembly language.
Rust came up in the context of this thread as a GC'd language, and it may
be worth mentioning that Rust uses manual memory management; the language
just introduces some facilities that make this safer. For instance, the
concept of ownership is elevated to first-class status in Rust, and there
are rules about taking references to things; when something's owner goes
out of scope, it is "dropped", but the compiler statically enforces that
there are no outstanding references to that thing. Regardless, when dealing
with some resource it is often the programmer's responsibility to make sure
that a suitable drop implementation exists. FWIW, I used to sit down the
hall from a large subgroup of the Go developers; we usually ate lunch
together. I know that many of them shared my opinion that Rust and Go are
very complimentary. No one tool is right for all tasks.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 6350 bytes --]

  reply	other threads:[~2022-02-06 14:15 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
2022-02-03  7:44         ` markus schnalke
2022-02-03  8:18           ` Rich Morin
2022-02-04  2:23           ` Adam Thornton
2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07               ` Thomas Paulsen
2022-02-04 23:18               ` Dan Cross
2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
2022-02-04  5:11             ` Rich Morin
2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37                 ` Richard Salz
2022-02-04 22:32                   ` Steffen Nurpmeso
2022-02-04 23:05                   ` Thomas Paulsen
2022-02-04 23:15                   ` Seth J. Morabito
2022-02-05  1:41                     ` Adam Thornton
2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
2022-02-04  8:10               ` Steve Nickolas
2022-02-04  8:44                 ` markus schnalke
2022-02-04  9:16                   ` Steve Nickolas
2022-02-04 18:54                 ` John Cowan
2022-02-04 19:45                   ` Thomas Paulsen
2022-02-04 20:28                     ` Hellwig Geisse
2022-02-04 21:03                       ` Jim Capp
2022-02-04 22:30                         ` Steffen Nurpmeso
2022-02-04 22:25                       ` Steffen Nurpmeso
2022-02-06  0:56                       ` Larry McVoy
2022-02-06  1:10                         ` Will Senn
2022-02-06  4:52                           ` Rob Pike
2022-02-06  4:58                             ` Dan Halbert
2022-02-06  5:06                             ` Will Senn
2022-02-06  6:19                             ` Ed Carp
2022-02-06  6:27                               ` Rob Pike
2022-02-06  6:40                                 ` Stuart Remphrey
2022-02-06  6:44                                 ` Bakul Shah
2022-02-06 19:08                                   ` Steffen Nurpmeso
2022-02-06 12:52                                 ` Ralph Corderoy
2022-02-06 13:14                                 ` Ed Carp
2022-02-06 14:13                                   ` Dan Cross [this message]
2022-02-06 14:15                                   ` Larry McVoy
2022-02-06 16:31                                     ` Warner Losh
2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:27                                     ` Jon Steinhart
2022-02-06 19:33                                       ` Warner Losh
2022-02-06 19:37                                         ` Jon Steinhart
2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
2022-02-08  5:22                             ` Ed Carp
2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).