Concurrency in Go vs Erlang

I've been writing Go for over a year and have successfully written a reasonably big library.

However, I've been interested in functional programming recently, and very sporadically using Go to sketch up quick API servers. I started learning Erlang and had drawn some comparisons between these two in terms of writing concurrent programs.

Erlang is a pretty quirky language for many, especially programmers who are more familiar with C-style imperative programming.

We all know that Go is pretty popular not just because of its simplicity, but also because of its two concurrent constructs which knocks socks off Node.js--channels and goroutines. In Go, spawning a parallel routine and interacting with it is so trivial and can be done the following way:

func main() {
        numchan := make(chan int, 1)
        donechan := make(chan struct{})

        go func() {
                fmt.Println(<-numchan + 1)
                donechan <- struct{}{}  
        }() 
        numchan <- 8
        <-donechan
}

Point is a channel is a godsend passage to which you can send values from any goroutine and many other goroutines can consume it with no data race. A Go channel makes sure each of the routines asking for a value from it is curbed and line up nicely (it implements mutex and semophore under the hood). As a programmer, you just have to trust the channel. You have no control or knowledge of which routine gets to the channel first.

This isn't unexpected if you think about it. Each routine is executed (hopefully) in parallel and they shouldn't have to concern one another's business. Take this example when you have a few URLs that you need to distribute to several goroutines to act like workers, each printing the status code from the response it receives from the URL after it has finished sending a HTTP request:

func printStatusCode(url string) {
        res, _ := http.Get(url)
        fmt.Printf("%d: %d\n", pid, res.StatusCode)
}

func main() {
        var wg sync.WaitGroup
        urls := [...]string{
                "https://google.com",
                "https://facebook.com",
                "https://dev.to",
                // ... thousands more
        }
        for i, url := range urls {
                wg.Add(1)
                go func(pid int, url string) {
                        printStatusCode(url)
                        wg.Done()
                }(i, url)
        }
        wg.Wait()
}

Each goroutine prints out its assigned pid (which is just the index of the url in the urls array) and the status code of the response received. Printing the index out is interesting because it lets you see that the goroutines execute in parallel and not in a synchronous order. sync.WaitGroup is used instead of a signaling channel used in the previous example. It makes waiting for many goroutines easier.

The key takeaway here is Go abstracts concurrency by means of channels. You can use channels for sending data to one or more routines and for synchronizing/signaling between different routines.

Let's look at how to achieve the same thing in Erlang.

In Erlang, the parallel executions are called processes. They are the same as routines in Go (at least for the purpose of this post).

Erlang does not have an intermediary like Go channel, but it does employ a very powerful concept known as the Actor Model. In this world, a process is an independent actor. It doesn't care about the outside world. It's like a prisoner churning over its own thing and wait for something to be passed into its prison's door, or more specifically, mailbox.

A process's mailbox is akin to Go's channel, but it is not shared. It's a private data buffer for that particular process to go through, one by one, synchronously. When a process sends something to another process's mailbox, that thing gets stored there until that process can make use of it.

Here is a small example doing the same thing as the first Go example:

main() ->
    P1 = spawn(fun() ->
        receive
            Num -> io:format("~p~n", [Num + 1])
        end
    end),

    P1 ! 8,
    ok.

What is going on here? How could you achieve that with so little code? Well, for one, functional languages are designed one level higher than most imperative languages. In imperative programming (in Go's case, structured, which is imperative), you mostly program to change some states, and thus you have to care about WHEN each line of code gets run (A changes state X, then B reads X is consequentially different from B reads X, then A changes X). In declarative programming, one expresses the logic without caring about control flow because each expression / function does not have side effects aka changing the state outside of itself.

This is why Erlang's actor model is so simple and powerful. It never has to care about data race or syncing because each process can never access anything external.

Each Erlang process has a small memory footprint and can grow/shrink dynamically. It does not share memory and only communicate through message passing. This is very similar to Go's solution of concurrency. Here is another Erlang sample equivalent to the second Go code:

printStatusCode(Url) ->
    {_, Res} = httpc:request(Url),
    {{_, StatusCode, _}, _, _} = Res,
    io:format("~p: ~p~n", [self(), Code]).

main() ->
    inets:start(),
    Urls = [ 
        "https://google.com", 
        "http://facebook.com", 
        "https://dev.to" 
    ],
    lists:foreach(fun(Url) -> spawn(?MODULE, printStatusCode, [Url]) end, Urls).

Now this got a bit hairy, but it did so because of the Erlang's bracket tuple literal than the way it does things. What is prominent here is the underscore _ repeating in several places surrounded by brackets. This is known as pattern-matching, a technique common in the functional world. This is because = in Erlang means "bind" versus "assign to" in Go. Thus, you can match the left-hand shape of data with the right-hand one like this:

{X, Y, _} = {"Joe", "Jim", "Jam"},
%% `X` is bound to "Joe" and `Y` is bound to "Jim"
[F | _ | T | _] = [1, 5, 2, 10, 54, 0, 98].
%% `F` is bound to 1 and T is bound to 2 

Go has something close to this behavior, and it's called multiple returns.

// Aw, not even close :(
a, b := func() (string, string) {
        return "Joe", "Jim"
}()

Since Go doesn't have tuple expressions, it needs to wrap a multiple return values in a function expression. And you can't pattern-match an array or slice.

One difference to note is Go is a statically-typed, compiled language while Erlang is a dynamically-typed, bytecode-compiled language. Go would of course be more superior in arithmetic computation such as image processing than Erlang. And being compiled to executable Go program is more portable than Erlang without the need of a virtual machine.

Questions, feedbacks, and advices are welcome. Please leave them in the comments.