249 karma · joined January 3, 2011
I've mostly worked with RoR, Clojure and Elixir and lots of infra/platform experience
Twitter: @orinj
https://traintimes.org.uk/map/tube/ https://traintimes.org.uk/map/tube/schematic/
Oban's been great, especially if you pay for Web UI and Pro for the extra features [3]
The main issue we've noticed though is that due to its simple fetching mechanism using locks, jobs aren't distributed evenly across your workers due to the greedy `SELECT...LIMIT X` [2]
If you have long running and/or resource intensive jobs, this can be problematic. Lets say you have 3 workers with a local limit of 10 per node. If there are only 10 jobs in the queue, the first node to fetch available jobs will grab and lock all 10, with the other 2 nodes sitting idle.
[1] https://github.com/sorentwo/oban [2] https://github.com/sorentwo/oban/blob/main/lib/oban/engines/... [3] https://getoban.pro/#feature-comparison
One trick worth noting, is that you can override the working memory at the transaction level. If you have a query you know needs more memory (e.g doing a distinct or plain sorting on a large table), within a transaction you can do:
`set local work_mem = '50MB'`
That will override the setting for operations inside this transaction only.
This is a non-issue if you're using a Elixir/Erlang monolith given its fault tolerant nature.
The noisy neighbour issue (resource hogging) is still something you need to manage though. If you use something like Oban[1] (for background job queues and cron jobs), you can set both local and global limits. Local being a single node, and global across the cluster.
Operating in a shared cluster (vs split workload deployments) give you the benefit of being much more efficient with your hardware. I've heard many stories of massive infra savings due to moving to an Elixir/Erlang system.
Embedded with Nerves, the various AI/ML libraries and tooling, LiveBook getting better every day, LiveView innovating and improving DevEx, etc..
Then there's fly.io pushing out content given their target market is developers and they have a big focus on deploying Elixir applications.
LiveView is also very close to becoming default over React for interactive Frontends.
At the beach, waves will hit everyone in their path (right place, right time) but only those that notice it and already have momentum in the direction it's heading are able to ride it. If they have experience, and the tools (a board), they can ride it for longer without crashing.
More recently i've used tools such as Retool (there are many alternatives), it has been ideal and allows for non engineers to build there own tools with a little bit of SQL knowledge.
[0]: https://htmx.org
That's basically how my team have been increasingly using it. Simply connect Livebook to a locally running Phoenix project and you have a Livebook REPL into your server. When you're dealing with complex data, pulling from different sources and have to build up a bunch of context before you iterate on a function it's super useful to be able to break up that code into chunks, take form inputs[0] along the way and document any quirks. We keep a bunch of livebooks committed in the repo to help debug and iterate on the more complex parts of our codebase.
Checkout this recent talk about how https://www.amplified.ai/ moved from Python to an Elixir ML stack: https://www.youtube.com/watch?v=Y2Nr4dNu6hI
Vulnerabilities are inevitable, the actions taken in the hours (ideally) and days following the discovery is what matters most.
I agree, the website is terrible at explaining what it is, I only got it by seeing it fully implemented in a business. It's too broad to describe here but this might help: https://www.youtube.com/watch?v=uF-GSj-Exms