> Think. Be careful. Write good test suites. Run them a lot. It really isn't so hard.

This mindset lead to countless security problems and other bugs in all kinds of software. Even now we still find exploits in sudo and openSSL. And the problem wasn't developers leaning back and saying "today I'm going to program carelessly and do a bad job because why the hell not".

Do we have good test suites for those programs? If so, could you direct me to the code for them? And of course these are run-once programs (not that excuses them)- I am talking about 24/7 stuff.

A run-once program can just as easily compromise the system with a single memory bug and some clever ROP programming.

You get the computer to do slightly more work in exchange for significantly easier development, plus you've obliterated entire categories of bugs that can be hard to trace (use-after-free etc).

GC was also originally developed for LISP; I'm not sure it's even conceptually possible to have a manually-manged lisp, although I think there's a refcount implementation somewhere.

It would be possible to have manually-managed Lisp. I think there is actually nothing in the standard which explicitly asks for a GC being present - just that there is no "free" function in the standard either. The GC of SBCL is to my knowledge written in Lisp itself. Carefully so, that no heap allocations are caused by the code.

This is not accurate. The SBCL runtime and GC are written in C because there are better tools in C for debugging the kinds of errors that one encounters at that level of the system. I can't find the note in the SBCL source repo but if you dig around a bit you will find it.

Which is anyway just one implementation.

Many tend to mix the choice of implementation language, with other criteria that the authors cared more about.

Common Lisp allows for manual memory management on the low level layers.

That is after all how Lisp workstations like Interlisp-D or Lisp Machines were implemented, and those features carried on into Common Lisp.

I’ve been writing high performance C++ for a while now and this is true. We rarely have memory leaks or use-after-free and when we do, they’re pretty mild. It is one of the easier problems to avoid, especially if you enforce standards on developers to avoid the most common mistakes (eg the new keyword should be avoided if possible unless providing an rvalue to initialize something safer). I can imagine new or bad developers without strong guidance, or under extreme pressure to ship, would have a harder time with it though.

Concurrency is a much harder problem and something we deal with more often. I would consider memory management close to not a concern.

> Concurrency is a much harder problem and something we deal with more often. I would consider memory management close to not a concern.

Absolutely. The longest lasting bug I've ever had was in some multi-threaded code in a trading server (and nothing to do with memory - shared resources getting corrupted). When I tracked it down (after about 6 months!) I repeatedly banged my head on my desk, yelling "You idiot, you idiot, you idiot!" - referring to me.

Compared to stuff like this memory leaks are really easy to test for, detect, and fix. Anyone can write a test harness to see if there is a leak.

>Even back in the day when I was writing BASIC programs (a long time ago now) I thought GC was pants, and spent some considerable time trying to avoid it happening.

Could it be that you never shed the bias from your young 80s BASIC experience, despite the world around you changing?

70s actually. And the world hasn't changed - if you want efficient, performant code that manages resources (not just memory) correctly, you don't want GC.

What BASIC were you using in the 70s that had garbage collection?

Among others https://www.wikiwand.com/en/BASIC-PLUS

Thanks! That's really interesting. There's a lot of material out there about BASIC for early microcomputers but most of what I've read about minis has been more focused on languages that were considered interesting to "hackers" (i.e. Lisp and C).

Why use a language with a GC at all if you don't like it?

> It really isn't so hard.

This doesn't align with the continuing serious security problems associated with memory-management bugs.

> The Chromium project finds that around 70% of our serious security bugs are memory safety problems.

https://www.chromium.org/Home/chromium-security/memory-safet...

Why not just use a language without GC?

I do. I'm suggesting that others do too.