Jobs may crash due to VM issues or OOM problems. The more common cause of "orphans" is when the VM restarts and jobs can't finish during the shutdown period.
For many accounts the audit log isn’t going to show some crucial information—git activity. Clone events are only available through the REST API for Enterprise customers.
The only reason I’m able to maintain a reasonably successful open source library is because it is part of an open core business model. Without that I couldn’t justify the development effort or relentless support to myself, or my family. Getting a few hundred dollars a month wouldn’t cut it either.
Building a business on a stack of other people’s hobbies isn’t sustainable. I mean, just tell that to anybody outside of tech and watch their reaction.
One of the best parts of listening to Elixir Outlaws, the podcast that Chris co-hosts, is disagreeing with his wacky and strongly-held opinions on things. Personally, I don't agree with most of what he's calling out here, but it's still a great read to get you thinking.
Running 75 million jobs a year would be totally fine. Depending on the configuration and load Oban easily runs thousands of jobs a second, and 75 million breaks down to less than 3 a second.
I’d argue it’s worth the switch, but I’m highly biased!
The size of Alpine and its package manager are brilliant. What gets me, and my team, is the support policy for “older” packages.
For a while we would pin library versions (e.g. libvips) only to have the pin break the build because the package was no longer provided. That’s only a few months later, not years. It seriously impacts the repeatability of Docker builds.
Now we don’t pin to the same extent and lack some confidence, but at least it doesn’t break the build.
Brian Called Brian: You don't need to follow me! You don't need to follow anybody! You got to think for yourselves! You're all individuals! You're all different!
There isn't an issue with Kafka and Elixir, it's the inherent complication around using Kafka when a lighter weight solution (Rabbit, PG) would work perfectly fine.
José is an enormous asset to the community and has an influence on many of the marquee projects, but it definitely isn't single-handedly done. He cares about the ecosystem and is very generous with his time and attention.
Anecdotally speaking, he hasn't been hands on with Oban[1], yet he still offers advice and guidance around the project because it is in the Elixir community.
According to the recent Thinking Elixir podcast [0] the performance is comparable. They specifically cite the performance of dialyzer, which typically runs through HiPE, as being just as fast with the new JIT.
From what I recall HiPE isn't widely used and will be (may be?) removed.
The IDE type tooling is getting better all the time thanks to Elixir-LS. There was a 0.6 release a couple of days ago with a ton of improvements [0]. Better auto-completion triggers and Ecto completion come to mind as huge quality of life improvements.
Rolling your own tools is an irreplaceable way to learn things thoroughly.
That said, HN readers from outside the Elixir should know there are great libraries for all of those use cases. Point in case is background job processors—we have plenty of options, though I’m especially fond of Oban[0] (full disclosure, I’m the author).
Anecdotally I don’t believe dual licensing is viable for smaller projects. There simply aren’t enough companies that care about your license to make it a reliable business model.
This is something I explored initially for Oban[0] and I interviewed a few successful OSS product owners. They attributed zero sales to licensing. All sales were driven by features that a business needed once they had already invested in the core project.
You make an excellent point here—it takes a lot of effort to get a solo project (OSS or otherwise) to be profitable enough that can compete with a day job’s salary. As somebody that is monetizing OSS, making a supplanting my salary is my measurement of success. At that point I can focus on my product and my customers during core working hours.
> Never use your primary DB as a queue. Using a separate Postgres instance can work if you over-provision capacity and don't need to maximize throughput, and a Redis-based solution can work if you don't need high availability and can tolerate some messages lost if something goes wrong.
That is a broad generalization that assumes most applications are operating at mega scale. The benefits of simplified dependencies (a single database instance), transactional guarantees (a single database instance) and persistence (not using Redis) far outweigh the eventual possibility that the queue will place too large a load on your database.
As the author of Oban[0] (an PG backed persistent queue in Elixir) I'm definitely biased. However, the level of adoption in the Elixir community seems to signal that a lot of companies favor simplicity and safety over a possible scale issue down the road. The primary application I work on processes ~500k-1m jobs a day and the queue overhead is virtually invisible.