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? 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. Using malloc and free might be a badge of honor to some, but it's also a failure of automation. 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. -rob 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" > > 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. > > 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. > >> > >> > >> > > >