Lambda the Ultimate

How does Erlang handle a process that is waiting for a message that will never arrive because no one knows its PID any longer? Seems like rather than eliminating GC, it just moves up a level and becomes a harder problem (distributed GC).

Erlang processes are like in Unix: explicit termination and not garbage collection. My impression is that distributed GC is not practical for applications that handle partial failure (i.e. real programs :-)

So this means if you are to subsitute processes for shared objects, you are eliminating GC by going back to manual resource management with all the same problems: leaked processes, dangling references to dead processes. It is not like programming without using free() since explicit process termination is equivalent to free().

A process can terminate, which automatically does the clean-up. If you spawn a process to do some computation, once it sends back the result it can just go away, no action from the caller required.

Still, I agree, you wouldn't want to map objects to processes one-to-one.

This sounds a lot like stack-based allocation/deallocation used in C/C++: "If you call a function to do some computation, once it returns the result its stack-based memory can just go away, no action from the caller required." Using processes in this way would seem to be equivalent to allocating everything on the stack, wouldn't it?

If you immediately wait for acknowledgement from the spawned process, and each process terminates before the caller does, then you essentially have stack allocation (which is still an interesting way of dodging GC). But that's only one way of working with processes.

For certain values of "manual" I'd consider type systems that effectively require you to prove all resources eventually die and give you room to prove when to be a way to allow manual memory management in a functional language - the region calculi underpinning MLKit and the like'd be an example.

Not to mention closures in general.

I will stick to my guns. You could meaningfully write e.g. Haskell programs without a garbage collector if you made them into cooperating Unix processes that will each terminate before generating too much junk. You could even keep them referentially transparent if they are just reading each other's results.

I had expected GNU utilities like ls, tail, and cat to take advantage of their short life span to ignore resource allocation but I just checked and it ain't so! For example cat can take many filenames as arguments and will close each file after copying and reallocate its buffers to match the next file's storage medium.

Details details details!