Being a Gopher this was the most interesting part. Concurrency with Erlang. Similar to go, you have a function called spawn. Using spawn we can spawn a basic receive loop that will pick message of a queue and match them to some function within receive.
Processes communicate between one another with message passing. It’s no accident that Dr. Armstrong calls Erlang a true object-oriented language! It gives you message passing and encapsulation of behavior. We’re just losing mutable state and inheritance, though it’s possible to simulate inheritance, and more, through higher-order functions.Bruce Tate
Then it goes on about how to improve reliability by signaling a linked twin process when a process is about to die (a doctor process, to revive it). So that we can react accordingly (similar to a panic defer in Go). The most robust fault-tolerant systems are built by accepting failure and restarting the process if it dies (the “Let it crash” philosophy), instead of handling errors constantly.
All of this was very important for the Erlang challenge I’ve got in mind. But first, the exercises!
Translate service with simple recovery
Monitor the translate_service and restart it should it die.
Translate service with doctor monitor
Make the Doctor process restart itself if it should die.
Make a monitor for the Doctor monitor. If either monitor dies, restart it.
All this is an abstract erlang module we’ll call the doctor that will check our service, instead of our service checking itself. So we remove the watch_loop from our translator_service module.