It will be a performance issue at some point. It creates a lot of allocator & GC churn. Part of the reason this is mitigated somewhat has to do with how the B

It will be a performance issue at some point. It creates a lot of allocator & GC churn. Part of the reason this is mitigated somewhat has to do with how the Beam VM manages GC. It's per process, which provides a few nice features. One is that processes that do a lot of "work" tend not to be long-lived, and consequently they tend not to accrete a lot of heap allocations. The share-nothing concurrency model enforces an isolation pattern on the developer, which then allows the GC to make some guaranteed assumptions about what is safe and isn't safe to reap. The combination of those to factors allows GC sweeps to be both typically small/short and also done in parallel with other scheduled running processes, so that GC doesn't block all the execution resources. Considering the use case here though, I'd really not worry about it. The only way it'd likely bite you is if you were building a massive scale email pushing application, and you were weirdly trying to optimize for using as low-end, or as few, machines as possible to run it, and you hadn't already found yourself flagged by every mail relay as being a spammer.