Can you speak a bit more about what you’re trying to do at a higher level? Links are used to establish lifecycle constraints, not really to setup messaging routes or something. If you can articulate what you’re after we can suggest a more idiomatic approach.

https://github.com/CorticalComputer/Book_NeuroevolutionThroughErlang/blob/master/Ch_6/simplest_nn.erl

shows the simplest approach that was used for the Handbook of Neuroevolution Through Erlang. Each process holds the pids of the other processes it needs to communicate within its state.

• The sensor process sends messages to its neuron process (N_PId).
• The neuron process expects messages from its sensor process (S_PId) and sends messages to its actuator (A_PId) process.
• The actuator process receives messages from its neuron process (N_PId).
• The cortex process sends a sync message to the sensor process (Sensor_PId) to initiate the sense_think_act cycle. It knows all three (Sensor_PId,Neuron_PId,Actuator_PId) so it can terminate them.

In this case, you could maybe use pg2, which is an Erlang built-in module that handles process groups, allowing processes to register under a given name, and then sending a message to one, all or some group members.

Another thing you might try, is to use something like Flow, which allows you to work with a producer-consumer-type interface directly. So after setting up the connections and specifying what each of the neurons should do, Flow will handle the inter-process passing on of messages for you.

But maybe the neurons of a neural network are not the proper level of abstraction to split it into multiple processes, since each of these neurons is probably extremely simple: If you have a system in which most of the processes cannot do a lot of work without communicating with a large number of other processes, the message-passing part itself might become more of a bottleneck than what you solve by splitting your neural network up into processes like this.

Another option, especially if it is a multi-directional graph, would be to use the built-in :graph module to hold the PID ‘links’ then with a wrapper module around that then you could ‘broadcast’ to all that are linked to you or vice-versa. If the graph is built once and never/rarely changed that embedding it into that module would be super fast, otherwise could probably encode it into ETS carefully as well sans the graph module).

If however it is just a simple list of send to things in this group, then pg2 or gproc (or maybe Registry) would be dead simple (I’d probably use gproc, but only because I know it best).

As @benwilson512 noted, the ‘linking’ process that is normally used is only to ensure that two processes that depend on each other will die as a whole when one of them dies.

The linking you are referring to would just mean exchanging the PIDs and sending a message to the PIDs you know at a later time. Why would it be wrong here to ‘bother about PIDs’? You can see the neural network represented then in the same way as a social network is represented with people using phones: When I get an important message, I can (and will) send it to the people whose phone number I have. PIDs are processes’ phone numbers, nothing more, nothing less.