Not OTP, just Erlang processes (memory isolation) and process links (an apoptosis signal, though here it seems pretty limited, to killing a supervisor only whereas Erlang can propagate death signal quite arbitrarily, including from children to supervisors or to unrelated processes without the dying process having any knowledge of the link).

I don't understand why TFA says this does not exist anywhere else (let alone suggest it could be implemented in Erlang when erlang already goes quite far beyond that)

I'm not very knowledgeable about either Erlang or Go. But from what I read, Erlang doesn't share objects between threads whereas Go does. This is a serious difference, because as the article mention you have to decide what to do if there are references from other threads. That's why the parallel with processes breaks in the case of Go. Cleaning up the resources of a share nothing (or little, and in a centralized place, see shared mem) process is easy and fast. Cleaning up the resources of a share most/everything thread... not so much.

> Are the concepts described in the article the same as Erlang/OTP, or is there more to it?

seems to be identical to what already exists in Erlang. it is pretty easy, imho, to have an appropriately defined 'terminate' in a 'receive' clause, of an erlang process. on receipt of the said message, erlang process can exit out of the event-processing loop, thereby terminating the process.

not sure why author thinks this is not present in Erlang.

this is part of the core language, and has nothing to do with OTP, which is a framework built on top of the language.

edit-1 : clarified OTP's role (or lack of it).