From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24608 invoked from network); 6 Feb 2022 06:44:32 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 06:44:32 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6BAED9CC43; Sun, 6 Feb 2022 16:44:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AD6F69B8B1; Sun, 6 Feb 2022 16:44:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=iitbombay-org.20210112.gappssmtp.com header.i=@iitbombay-org.20210112.gappssmtp.com header.b="4vrLNCFX"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C493E9B8B1; Sun, 6 Feb 2022 16:44:16 +1000 (AEST) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by minnie.tuhs.org (Postfix) with ESMTPS id CB6239B68F for ; Sun, 6 Feb 2022 16:44:15 +1000 (AEST) Received: by mail-qt1-f175.google.com with SMTP id t17so9338769qto.1 for ; Sat, 05 Feb 2022 22:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VCGz4y0jAe6MqnQD8fLVxBleU/ST0ZV3k70UmZyKftA=; b=4vrLNCFXMweIT58KQAsBKgQTBeiIu7aC+YfNOGu6bKqC8i+poMlplt/LMNZPhfMYt7 2O3MuGEunIZLgxJcqf6nUywEE94ftdh7hR+V7Jdxo/k4Rw9XmtmXFh6e2Kj1yIjtLIiF Xg5sJRr0v4b6sYujkKdGsRAekfShfA7LsZmWkCf5W8AzWi7j2gRTbAjfMsbVciOPxyWJ BXFI0eTWzfBEjl1bH3s0E6+AzhQAE3OtJg0X0vMeMe4KSNngFEb1H9c4+66YRSSLl2lt BIoaozBtnTFUKWcFiybEFg4HEAovFxUnkhySQPOnLf/UBRa7R/q3B0o5wQ/uc0pqxfUr YE+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VCGz4y0jAe6MqnQD8fLVxBleU/ST0ZV3k70UmZyKftA=; b=7hevMmlyId7apwn5feFsQSXjqvmOyzGk6UBTfttgpkjp0/I2XREnSRz7FNRDHYP5s+ 0PSM7/wOkAHkCQoythVTYJZNJgzw9pDviMxPHGCpK9/KQ/uFZKtUZIKHycN9KFRoREE2 JzCiRd/UageAr6aNwmFiZkpwipKt8woIkRVldCndosXw82/wHnPQll/+OaOdd2wIC0ge w7aU9rUaV9/Q/WTSZpgYCvdqgfQMLvAcWwp3FWlrofKalUrwIV19SOoi0wssPqrvBC6d jhXd/ZWrkN/DgqM9mESenLMSLABIFZzLdKfCzGLGXe6sJSDU2uNdbxLMqx11h8clkqQq mmnw== X-Gm-Message-State: AOAM5317TG7I2N0y/VRBTNsAbCAZ6X9DG/Mk+/pW/w2mYDR4TRc3kEmB iC6Ji6OkFxd/WyD/DWwY7x/wGOHxOvDA0w== X-Google-Smtp-Source: ABdhPJzalksbmDW50JoPId5U0Os09WUhKUCozlhFHWTdcudmOKvC1spWHd53uZX5r4kNL/UhnhIIoA== X-Received: by 2002:a05:622a:20a:: with SMTP id b10mr4336275qtx.291.1644129854762; Sat, 05 Feb 2022 22:44:14 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id y15sm3594598qko.95.2022.02.05.22.44.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Feb 2022 22:44:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Bakul Shah In-Reply-To: Date: Sat, 5 Feb 2022 22:44:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> To: Rob Pike X-Mailer: Apple Mail (2.3693.60.0.1.1) Subject: Re: [TUHS] more about Brian... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Just ignore the swagger. I would go further than Rob in that even for sequential programs there is no virtue in sticking to malloc/free if you don't have to. The whole point of automation (for me) is to delegate all the boring and repetitive work to computers so that I can focus on more interesting things! And solving malloc/free related bugs is boring and repetitive. For embedded code in limited space you want to use memory carefully but for most of userland code we don't have to worry about saving every byte. Most userland code is not real time code (and doesn't run on realtime OSes). That doesn't mean using memory like water -- there is a middle ground. Don't blame the GC for incompetently programmed websites or for layers of code using third party libraries using other third party libraries. > On Feb 5, 2022, at 10:27 PM, Rob Pike wrote: >=20 > I don't understand your disagreement. In what way is automatic memory = management harder, more unsafe, and less robust than hand-written memory = management using malloc and free? >=20 > You seem to think that garbage collection only exists in languages = that have a smell you don't like. Perhaps that's true, but it's been = around for 60 or more years and a lot of important languages use it, = while the programmers that use those languages are often quite capable. >=20 > Using malloc and free might be a badge of honor to some, but it's also = a failure of automation. >=20 > 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. >=20 > -rob >=20 >=20 > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp wrote: > "it's a lot easier, safer, and robust to let the machine do the memory > accounting" >=20 > I disagree. "The machine" is, as you know, is in reality app code > built on top of frameworks built on top of libraries built on top of > more libraries built on top of malloc/free calls. While the automated > testing tools are a lot better than they were when I started coding C > back in 1985, we're still talking about a *lot* of complexity and a > lot of layers of code, and programmers today know far less about > things like boundary conditions, off-by-one bugs, and the like that > bit us in the ass - hard - and so we learned to watch for those sorts > of things. >=20 > On 2/5/22, Rob Pike wrote: > > Be careful with your castigations. Yes, there is lots of old working = code, > > but keep in mind that that code has often not been as widely tested = and > > deployed as much of the software that runs today. The fact that it = worked > > well on old hardware doesn't mean it will be suitable for modern = networked > > remotely administered multicore machines pounded on by millions of = people. > > > > And speaking of multicore, it's possible to write code using = malloc/free > > that doesn't leak when run concurrently, but it's a lot easier, = safer, and > > robust to let the machine do the memory accounting. And the fact = that "kids > > today" can't do it doesn't mean they are lazy or failures, it means = they > > grew up in a different time. And a lot of them are as capable as you = all, > > just in a different environment. > > > > Lately this list has a lot of attitude and prejudice pretending to = be > > wisdom and superiority. > > > > -rob > > > > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn = wrote: > > > >> On 2/5/22 6:56 PM, Larry McVoy wrote: > >> > >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > >> > >> Hi Thomas, > >> > >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > >> > >> I tell you one thing: I never ever experienced any problems with > >> traditional malloc()/free().?? > >> > >> did you ever write a program which does heavy malloc()/free() > >> on complicated (i.e., shared) data structures *and* runs for > >> days, perhaps weeks? IMO it's very difficult to do this without > >> a GC, and you have to exercise quite an amount of discipline > >> to do it right. > >> > >> I've done this and I've employed people who have done this. We're > >> a dieing breed, the focus seems to be on programming languages and > >> tools for idiots. People don't want to learn the discipline it = takes > >> to work with malloc()/free(). It's sad. > >> > >> > >> I completely agree. This is ridiculous. Do modern programmer's = seriously > >> think that the old code wasn't complex or robust? Sheesh, there's = code > >> out > >> there that has run through more millions of transactions an hour = for more > >> years than most of these folks have been alive. There's also code = that's > >> been running without any updates, for decades. Most code written by = the > >> newbreed won't run for a month without surfacing dozens of bugs. = Margaret > >> Hamilton would prolly have some choice words for these folks. > >> > >> > >> > >