This is a great example of using a python library within Elixir:

https://github.com/nelsonmestevao/pdf_extractor/blob/main/lib/pdf_extractor/pdf_plumber.ex

This means we can easily turn a python cli application into a managed Elixir webservice.
If we don’t have a native Elixir version we are free to use a Python one.
Keep these in small services as it may not play well with a supervision tree!

Elixir finds lots of ways to work well with other languages!

I recently wrote a useful application that does not have its own UI. Your users probably already have enough primary applications to work with so adding another will make their life more complex.

Instead the application writes the data it finds into the application they are already using. I have used this technique now with Contentful, Teams, and now Zendesk.

The trick is to combine webhooks from the application with some form of comment API to write what you need where the users are already working.

In this case I notice that a ticket has been submitted with some metadata and a well known pdf structure. The app reads the pdf, parses it and checks the details against what we have stored on our systems. It also writes both back to the ticket with a list of differences. This means that the user does not need to open the attachments (or our system) to start work.

This is not a language flamewar.

Each language has its focus area.

Rust wins on CPU bound operations while Elixir wins on IO bound ones.

I have been working on a small utility service in Elixir. It accepts a webhook to start. This spawns a process to do the work. The main work is a series of steps unified by a with block. The beauty is that it is all in small isolated files that you can see what it is doing. Having a repl in iex allows you to quickly experiment with services to see what is not working.

I am trying to read an equivalent Rust project to see how one of the system callx is used. Rust is high ceremony so there are many distinct declarations. The habbit of embedding the tests in the same files as the code makes searching for details far more painful than it needs to be.

Recently I reread Competitive engineering.

One of the interesting points that I remember this time is the figure given for unfound errors after a review. It argues that any review will only find 1/3 of the errors present.

This makes the case for many small reviews!