Actually, lack of a GC is overkill (in terms of control needed over memory) for most command line tools.

Having to manually track memory liveness C adds a large amount of complexity to tools like awk, sed, grep (which are already complex beasts themselves).

Many commands that only do a few things (perhaps not awk, since it runs full programs) don't need to free everything, since it will only allocate a few things and will soon terminate and free the entire process.

Nearly any command that you pipe into, or stream content out of, must to allocate and free memory in some non-trivial way.

Sure, those commands could just allocate and never free memory (a-la early C compilers, or the D compiler), but now any use-case that involves a large amount of data will leak noticeably. Not going to fly if you need these commands to be durable and efficient. And unix commands need to be both.

A GC gets you the freedom to operate on large streams for free, without having to worry about memory management (modulo optimization, but that happens later anyways, regardless of GC presence or not).

In some cases, yes. But not in all kind of programs. For example, my Farbfeld Utilities programs, are different how much buffers is needed:

* Some deal with only one pixel at a time, or sometimes two. No dynamic allocation is needed.

* Some deal with one scanline at a time, or sometimes more than one (but a fixed number) at a time. The same buffer can be used for each scanline.

* Some deal with the entire picture (such as those that distort the picture).

But one possibility can be that a program might load multiple pictures and each picture needing the entire picture at once, but does not use them simultaneously, in which case it is sense to free each picture after it is used.

(Or maybe I somehow misunderstood your message or something else.)

The point is, the default decision should be to not have to worry about memory management. Most application shoudn't, because they're not realtime operating systems, or in an environment where memory must be allocated statically.

Almost all unix command line utilities fall into this category. Having to worry about pairing your `free`s with your `malloc`s is a strict increase in cognitive overhead, which should have been spent on verifying the program's semantics are correct.

Messing up low-level memory operations, when you just want to worry about semantic correctness, potentially leads to bugs like RCEs, or dosing somebody with too much radiation.

Thankfully, these days, you don't actually need to choose between GC and manually matching up your `free`s with your `malloc`s.

There is at least some data that GC does have an impact on command line tools like this: https://boyter.org/posts/sloc-cloc-code/ --- More experiments like that would be great to crystallize the exact trade offs here.

Go isn't just about GC. Go is a language, which is stricter checked by the compiler. So beyond direct memory management, Go code should be cleaner, safer and of course easier to read than the corresponding C code.

If you're interested in correctness, cleaner and safer, Rust is a better choice. Go's lack of generics really hurts it when it comes to simplicity and cleanliness, and so far as correctness goes, the Go compiler isn't anywhere near as strict as Rusts one (nor is it as strict as gcc or most other compilers, for that matter, as a conscious choice of favouring speed over correctness)

Easier to read is not something I'd particularly accuse Go of. If you want that, stick with python. Lack of generics can end up really hurting Go for cleanliness.

Something I ran in to the other day when I was trying to produce a reverse sorted list of strings:

    sort.Sort(sort.Reverse(sort.StringSlice(dir_contents)))