Minor clarification -- Erlang is not interpreted, it's compiled to bytecode and executed on the BEAM virtual machine.

The major problem, without any measurement and just guesswork, is that you have a larger allocation overhead in Erlang. Not only do you need the process control block for the process, you also need to go to the memory subsystem and grab a heap for the process. In the Go variant, you are allocating out of the same heap and you can usually avoid some allocation there because everything you allocate is used. Not so in the Erlang system.

Were these processes/goroutines to do anything more complex, then the difference goes toward zero. But the constant overhead at the lowest level is probably higher.

I don't think the lists would have to be collected, erlang processes have a relatively hefty private heap (233 words) by default, so chances are the process just dies without needing to run a GC[0]. The lists do need to be allocated and initialised though, which may or may not contribute to the runtime.

[0] the way I understand it, each process would generate a 10-elements list of small integers, which would be 21 words (1 word + 1 word/element + the sum of the element sizes — 1 word each for small integers)