I don't really understand this sentiment of not needing a queue system. This is not much different from spawning a thread in Java to delay the email sending.

For any serious application you want a job like that to be persisted so you can guarantee it runs even if your application is restarted.

I know that Erlang/Elixir is designed for stateful applications and if you have a cluster and do hot deploys this is less of a problem, but who does that? Most Elixir applications I've seen are deployed as stateless systems just like any Ruby, Python, Node etc systems.

Slightly offtopic, but consider a pattern of persisting the state machine of a given task instead of the task queue itself. For example, for a daily email job, you might have three states: UNSENT, BEGIN(begin_time), SENT. Then you can just have a supervisor job that scans your table or whatever and schedules jobs, retries, etc. as needed. Now you don't have to worry about the queue state at all!

Having a queue means you have a distributed system. How do you handle network problems, errors/retries, back pressure? OTP has excellent idiomatic tools for all that and more.

Elixir developers who need a queue generally reach for Rabbit (which any language can use), or something backed in a database like rihanna[1] or honeydew[2]. Rolling your own distributed system is very much a last resort, and despite its excellent concurrency characteristics the BEAM still lacks basics such as a battle-tested raft implementation.

[1]https://github.com/samsondav/rihanna [2]https://github.com/koudelka/honeydew

> and despite its excellent concurrency characteristics the BEAM still lacks basics such as a battle-tested raft implementation.

A couple of years ago the RabbitMQ team has published a raft library[1] which they use in their implementation of persistent queues. It has a flexible API and implementing your own state machines is quite straightforward, as it follows the OTP gen_* behaviour paradigm.

And by now, I'd say it's pretty well battle-tested.

[1] https://github.com/rabbitmq/ra

I didn’t know about that - thank you for pointing me at it!

Wait, how does that answer prevent only one instance of the job across the whole system? That's what I'd use Redis or something for - for locking.

If there is only one process running this GenServer, there will only be one instance of the job in the system.

An BEAM process, and therefore a GenServer, has an atomic message queue built in. Only the process itself can pop messages out of its queue, so there is no need for locking. It is not possible to get messages out of the queue concurrently. Messages can be processed concurrently, but that's after they've already been removed from the queue.

What if you have 100 servers running the same application code and you just want to run this job, one time, for a customer? Usually I'd use a Cron with a distributed lock, which is served via Redis.

Just curious as to how the BEAM solves it as I imagine it can.

You can use tricks like the global spawn option to make processes globally unique. Doesn't scale infinitely, but for a 2->low double digits HA/load balanced system it should be fine.

Oh wow, so this will work across multiple instances of the BEAM?

If they are clustered using erlang clustering, yes. https://erlang.org/doc/man/global.html

Note that this works by taking a transaction lock on the entire cluster, so it's not recommended if you're making requests frequently. It also doesn't respect netsplits, unless you instruct in code to fail with a deficient cluster membership.

How is that stackoverflow answer good?

You lose everything about the scheduled jobs when your app crashes.

This doesn't even address the rampant memory leak issues that plague long running genservers.

Some jobs don’t need persistence, or might have everything about them stored in a Postgres DB. Examples: I have a project where I render lots of little PDFs as previews for a LaTeX editor. My use case means it’s good to keep them around for a short while; after an hour or so I want to delete them all so they don’t fill up my disk. Perfect case for this. The question mentions rebuilding a site map—that sounds like it doesn’t need to persist much state. Finally, at my work we have orders that sit in a Postgres DB that we regularly check to see if any are stuck. We do use the Quantum library for that, but a solution like this could theoretically work.

> Rampant memory leak issues

As long as you’re not sending this genserver bogus messages, I don’t see how memory would leak in this example. Erlang applications are known to run uninterrupted for years at a time, so I figure this is a solvable problem.

When you do need persistence for more robust job scheduling, yes, having a real queue system in place is much better. You are correct there. I think the answer is good because it is so small and fits these simple use cases—the fact that you can handle those cases without needing something heavier is pretty awesome.