pselbert

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.

How in the world does DocuSign have 7k employees? I’m genuinely baffled. 700 employee would seem like a stretch.

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.

Couldn't help but think of:

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!

Man: I'm not...

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.

1: https://github.com/sorentwo/oban

That project is fantastic! I'll soon have need for some clean SVG language icons and these are perfect.

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.

[0]: https://thinkingelixir.com/podcast-episodes/017-jit-compiler...

No idea. It is the foundation of VSCode and most of the other plugin systems powered by the language server standard.

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.

0: https://github.com/elixir-lsp/elixir-ls/blob/master/CHANGELO...

A lot of people have been moving from Exq to Oban. Come by the #oban channel on Slack if you have any questions.

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).

[0] https://github.com/sorentwo/oban

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.

[0] https://getoban.pro

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.

[0] https://github.com/sorentwo/oban

“Please excuse the crudity of this model. I didn’t have time to paint it or build it to scale” — Doc Emmett Brown (Decidedly not Google)

Possibly a bit of a stretch, but to my mind more business for Ericsson means more guaranteed support for Erlang. That's something to celebrate about in my book.

No matter whose billboards they are, I would rather not have any. They are a blight on our environment—drive on 294 around Chicago if you don’t believe me.

I love DDG and am a long time user. I’d just prefer that nobody had billboards.

Indeed. It was from their parent company. I’m a fan of their scotch, so it’s a little bitter sweet.

There is a service ran by ICANN called the “trademark clearlinghouse”. It is a subscription service that trademark owners, e.g. Netflix, can use to be notified of any domain that is registered and may infringe on their trademark. It even allows for wildcard patterns in ongoing searches.

How do I know this? Because i received a takedown notice regarding a domain I run to sell background job licenses (oban.dev). The business is entirely unrelated, but the clearinghouse alerting system still brought it to the trademark holder’s attention.

Thanks for the thoughtful feedback.

We're trying to prepare for an alternate name and all of the changes that entails and hoping that a domain change is sufficient.

Anything from Oxide’s On the Metal podcast, especially the first five episodes.

https://oxide.computer/podcast/

Searching for things related to Phoenix is a constant problem. Even Phoenix Elixir will sometimes give you results for random bars in Arizona.

During the coding exercise portion of an interview I let them choose any language they like. The exercise is exceptionally simple and doesn't push the boundaries of their language knowledge at all.

If somebody can't do the exercise in their language of choice I have doubts about their competency in general. That seems different than asking arbitrary questions about specific language constructs.

I use it professionally about 90% of the time, and for my own projects almost 100% of the time now. I’ve been in the community for about 6 years and still absolutely love it.

This is my primary issue with just about every sizable library in the JS ecosystem. All I need to do is concatenate some files and convert ES6 and now I have 700+ packages in my node_modules folder.

I wish core JS had more functionality built in to alleviate the need for all these tiny packages.