Writing A Job Runner (In Elixir) (Again) (10 years later)
github.com
github.com
Overall, I'm wildly impressed at how this Elixir code held up, and it was a joy to revisit this.
Such a pity the industry (customers) reacts with skepticism every time I propose solutions based in Elixir/Erlang. I always hear: "Elixir, what? We want Java/.Net/Python/php"
The one Danger Zone area though is when they want something between WordPress and a "real" app. A lot of the clients I've talked to already have WordPress and are really trying to stretch the framework to places it isn't really made to go. Those customers often think "I should be able to get a full app built for <=$10,000" and often shop around until they find someone who will accept it, and then they usually end up getting a bad/buggy product that is slow as dirt. At that point it's often too late as well because nobody wants to pay to start over. For those clients though I wouldn't recommend Elixir because they would almost rather spend more in maintenance costs than in initial development because the numbers feel smaller when spread out, even if they add up to more in the long run and with a much worse product.
That is not to say of course that any Elixir app is going to be better - there are bad Elixir devs just like any stack, though I think Elixir's relative lack of popularity actually leads to an overall more skilled dev pool.
In the context that doesn't really say a lot, they pay the floor guy and the architect to solve problems, just different problems.
>they are trapped in an institutional/corporate mindset (old patterns are most suitable, 'best practice', 'reliable, proven tech' and such)
While true, it is also correct. From their perspective Elixir is an exotic material, the next "one they pay to solve their problems" is not going to know how to work with it, scrap it, and start over. Therefore the Elixir solution isn't a good solution for them.
As a business man once told me, "I never saw a feature I liked so much that I was wiling to pay for it twice."
And I say this as an elixir employer and whose company has done only elixir projects for 8 years.
In all cases though, our client just wanted us to solve a problem and didn’t care how we did it. So we’ve been very lucky. But have also earned their trust over the years by delivering.
The worker is stateless and "dumb" by design (currently it runs on serverless functions) - it just calls SQL functions: "poll_for_tasks" to get some tasks from the queue and then either "complete_task" or "fail_task" after executing user code - that's it, nothing more, so it should be relatively easy to adopt it to other runtimes.
I have written a small architecture primer on pgflow if anyone is interested in its simple but flexible design https://www.pgflow.dev/concepts/how-pgflow-works/
https://viewer.diagrams.net/?tags=%7B%7D&highlight=0000ff&ed...
Wouldn't you say these patterns aren't unique to event based systems since functional composition can also lead to these patterns? For eg: see the Streams API in Java
========= - Where would push event systems make sense over pull based systems?
You can rant all you want about the disadvantages of OOP and other paradigms. But after your rant, do not come up with an even more absurd type system that gives you even more work to do without any upside.
Building a project out of constructs such as macros does not scale with project size or team size. The only aspect that scales is the resulting size of the unmanageable spaghetti. Tolerating having that as a widely used feature in your language and then praise it as being fantastic truly makes one wonder what are you comparing the Elixir experience with? Elixir is fantastic compared to... fighting 100 gorillas blindfolded.
There are good choices built into the language, like railroad oriented programming. But those will never undo the infinitely awful and inadequate insanity of having to deal with macros to survive.
And to be frank, even if there are use-cases where the language shines and can be excellent tool for the job, most of the time those are not your use-case, and most of the time your team is not familiar with the language enough to leverage its advantages or build something production-worthy.
And if you ever go through the pain of mastering Elixir, 99.99% of the time your next job will not use it. If you are at a startup celebrating the virtues of Elixir before having enough revenue, your next non-Elixir job is closer than you think because your company will run out of money. And if your plan is having a LLM help you write Elixir faster before you burn through your budget? Good luck debugging a labyrinth made out of AI generated macros, your on-call rotation will go great. Your stakeholders will be eager to learn more about how great Elixir is when they ask for an explanation of why nothing works, an estimate of when it will be fixed, why is the project late or how can they add more team members to make it go faster.
I think they are mostly useful if you write libraries.
Also FOR UPDATE SKIP LOCKED is interesting.
One thing worth looking into if you do this in production is adding a way to add partitions such that each partition is single threaded. It’s the only way to guarantee ordering if your jobs are doing anything non-deterministic.
We increased partition counts on sale days and it works well for us.
Couple of gotchas we had were.
1) Using hashtext from postgres is sketchy.
2) Increasing partiton count is an orchestra which requires stopping the partition.
Claude says you can use a CTE to select and the run your update with the locked rows, but I have only ever used transactions.
sigh. anyway. i had the same reaction to acme. but I'm lazier. i just ran ngix and the acme client in qemu and picked the certs out. i applaud the author for her tenacity.