In a way, your reply highlights my confusion.

> Go has both value types and pointer types...

but:

> My reading of the COBOL part was that it's basicall like C and C++ without pointers.

But the author also says C is one of the COBOL derived languages: "COBOL-derived languages like C and Golang give the garbage collector an easier time, because they perform fewer, larger allocations; they tend to mutate the allocated objects instead of allocating modified versions; and programmers tend to nest records rather than link them with pointers where possible..."

Actually there are a few things about this passage that are odd, since C does not have a garbage collector.

Thank you for pointing out how that part is confusing! It's certainly true that C usually does not have a garbage collector.

As chubot said, what I was saying is that C and similar languages take (the simplified ur-form of) the COBOL memory model and add pointers to it, and programmers in these languages mostly use pointers when they want one of the things you can't get in the COBOL memory model: aliasing, nullability, cyclic relationships, or dynamic memory allocation.

You could very reasonably argue that the distinction between GC'd and non-GC'd languages is more profound than that, since in a GC'd language you can make all your data immutable and toss around entire subgraphs of the object graph as if they were integers, simply by referring to them by a pointer, not worrying when or if they get deallocated. While I agree that this is a big difference, I think the differences I'm focusing on in the essay are actually even more pervasive — so pervasive that we rarely even take note of them at all. That's why I feel justified in lumping Golang with C instead of Lisp here.

Yeah, I think thought he was basically saying that the records come from COBOL, and the pointers come from Lisp. So then C/C++/Go are derived from BOTH COBOL and Lisp.

I think he is being a little imprecise there but the meaning gets through. The point is that Go programmers can structure their data so as minimitze garbage collection overhead, but Java programmers can't. I'm pretty sure this was mentioned in some of the recent Go garbage collector design docs, so it's a pretty relevant point.

I always thought of C/C++/Go as ALGOL-like languages, but I guess that refers to the syntax (block structure) and not semantics (the data model, which I prefer over "memory model").

> The point is that Go programmers can structure their data so as minimitze garbage collection overhead, but Java programmers can't.

There is an anecdote that Minecraft, in the old days, used to pass around block coordinates as "int x, int y, int z" rather than as an instance of a BlockCoordinate class in order to reduce GC overhead. The BlockCoordinate class was introduced by a refactoring later on, thus turning Minecraft into the memory hog it now is.

So you can certainly optimize for GC overhead in Minecraft, though probably at the expense of readability.

> I think he is being a little imprecise there but the meaning gets through.

It's one thing not to go into details. It's quite another to misrepresent them. To describe C and Go as somehow alike in their memory allocation strategy, as though C were garbage-collected, is to foster a misconception.