José Valim joins Jerod to talk all about what’s new in Livebook – the Elixir-based interactive code notebook he’s been working on the last few years.

José made a big bet when he decided to bring machine learning to Elixir. That bet is now paying off with amazing new capabilities such as building and deploying a Whisper-based chat app to Hugging Face in just 15 minutes.

José demoed that and much more during Livebook’s first-ever launch week. Let’s get into it.

I’ve quit Elixir’s REPL by hitting Ctrl-C twice a zillion times, but I’ve never stopped to play with the BREAK menu provided between the Ctrl-C’s.

BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
       (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution

This article is a nice explainer of all the options and what you can do with each.

Jason Stiebs runs down all that you can accomplish in Elixir without a compilation step by running elixir my_script.exs, including the use of any hex package thanks to Mix.install/2.

I’m a big fan of Elixir, asdf & TUIs so this one’s a no-brainer share for me. The linked blog post by Mitchell Hanberg goes into the details:

While I find lazyasdf to be an amazing achievement for myself, it isn’t super interesting on its own. Let’s dive into the specifics of how I was able to build and distribute a TUI application with Elixir.

Source code here.

Lars is big on Elixir. Think apps that scale really well, tend to be monolithic, and have one of the most mature deployment models: self-contained releases & built-in hot code reloading. In episode 7, Gerhard talked to Lars about “Why Kubernetes”. There is a follow-up YouTube stream that showed how to automate deploys for an Elixir app using K3s & ArgoCD.

More than a year later, how does Lars think about running applications in production? What does simple & straightforward mean to him? Gerhard’s favourite: what is “human scale deployments”?

José Valim announces Bumblebee and walks you through how to run ML modules in Livebook with just three clicks. Finally, he shows you how to embed a model into a Phoenix app. So cool!

Andrea Leopardi likens database migrations to git commits and wonders why we don’t leave them in the past and load an up-to-date SQL file instead. He also shares his approach to this in Elixir.

I had the honor of joining the fine folks at Elixir SF awhile back to talk all about how we’ve been podcasting on Elixir for a long time now. Tune in if you’re curious about such things and/or if you’d like to take a stroll down memory lane as I show old versions of our album art and play our intro music along the way.

The preso is average, but the Q&A near the end is above average, if you ask me. OH! And also we got Zoom bombed twice, which was a first for me. Thankfully, it was also a last. So far, at least…

Few genuinely need a multi-cloud setup. There is plenty of advice out there which mostly boils down to don’t do it, you will be worse off. Vex.dev is a startup that provides APIs for video and audio streaming. The hard part is real-time combined with massive scale - think hundreds of thousands of concurrent connections. They achieve this by using a combination of Fly.io, AWS and GCP. Jason Carter, founder of Vex Communications, is joining us today to talk about the multi-cloud setup that vex.dev runs.

This week we turn the mics on ourselves, kind of. Lars Wikman joins the show to give us a guided tour through ID3 esoterica and the shiny new open source Elixir library he developed for us. We talk about what ID3 is, its many versions, what it aims to be and what it could have been, how our library project got started, all the unique features and failed dreams of the ID3v2 spec, how ID3v2 and Podcasting 2.0 are solving the problem differently, and how all of this maps back to us giving you (our listeners) a better experience while listening to our shows.

I helped build chapter support for Changelog podcasts. Let’s parse some ID3 tags!

Our shows have chapters baked in now, whoop whoop! This post details some of the challenges we had to overcome to get that done, including a brand new open source Elixir library for reading & writing ID3v2 tags.

In today’s Kaizen episode, we talk about shipping Adam’s Christmas present: chapter support for all Changelog episodes that we now publish. This feature was hard because there are many subtle differences in how the ID3 spec is implemented. Of course, once the PR shipped, there were other issues to solve, including an upgrade the world kind of scenario. Since Lars Wikman did all the heavy ID3 lifting, he joins us in this episode.

Why are the right values important for a company that changed the way the world builds software? How does pair programming help scale & maintain the company culture? What is it like to grow a company to 3000 employees over 30 years?

Today we have the privilege of Rob Mee, former CEO of Pivotal, the real home of Cloud Foundry and Concourse CI. Rob is now the CEO of Geometer.io, an incubator where Elixir is behind many great ideas executed well, including the US COVID response programme.

Michael Guarino lays out how the engineering team at Plural brought K8s to the browser for their users:

Overall, we had a ton of fun building this feature. It allowed us to delve into an often unexplored area of the Kubernetes API, which I am honestly happy that we got to explore. This project also took an unexpected turn in its use of tmux and exposed us to a genuinely mind-blowing project in xtermjs (I’m shocked the community had the patience to write a full shell in javascript!).

Sean Moriarity:

A common argument against using Nx for a new machine learning project is its perceived lack of a library/support for some common task that is available in Python. In this post, I’ll do my best to highlight areas where this is not the case, and compare and contrast Elixir projects with their Python equivalents. Additionally, I’ll discuss areas where the Elixir ecosystem still comes up short, and using Nx for a new project might not be the best idea.

Sean is a prominent member of the Elixir community, so that’s the perspective on display here, but it’s a thorough and well-reasoned comparison. He concludes:

While there are still many gaps in the Elixir ecosystem, the progress over the last year has been rapid. Almost every library I’ve mentioned in this post is less than two years old, and I suspect there will be many more projects to fill some of the gaps I’ve mentioned in the coming months.

A reasoned critique of the often lauded with keyword that can be summarized as:

Return values from different expressions in a with block can only be distinguished by the shape of the data returned. This creates ambiguity in with’s else clauses that make code harder to understand and more challenging to modify correctly.

The author describes the problem in detail and even provides two alternatives to with..else that avoid the resulting ambiguity.

Today we talk to Mark Ericksen about all the things that we could be doing on the new platform - this is a follow-up to episode 50.

Mark specialises in Elixir, he hosts the Thinking Elixir podcast, and he also helps make Fly.io the best place to run Phoenix apps, such as changelog.com. In the interest of holding our new platform right, we thought that it would be a great idea to talk to someone that does this all day, every day, for many years now.

We touch up on how to run database migrations safely, and how to upgrade our application config to the latest Phoenix version. We also talked about some of the more advanced platform features that we may want to start leveraging, like the multi-region PostgreSQL.

We’ve been using Parker Selbert’s Oban library for years and he even helped us hold it right by improving our open source implementation!

So, Jerod invited him Backstage to discuss the library, how we’re using it, Parker’s plan to make it financially sustainable, his “freedom number” of Oban Pro subscribers, and a bunch of other random stuff along the way. Let’s go!

Connor Rigby shows us how easy it is to embed Elixir’s IEx console like they do with Nerves.

As is customary around these parts, we aren’t going to write much code. Just glue it together. First up, we’ll need a handful of dependencies.

Plug, Cowboy, and extty do all the heavy lifting.

Good ideas get legs and run. It appears that “self-destructing” TODO comments is a good idea, because the concept has now been implemented in Rust, Ruby, Python, and Elixir (as a credo check). Here’s some insight on that decision shared by the package author, Brian Underwood:

I talked with a couple of other people on the Elixir Slack about it when I started and we all liked the idea of doing it as a check (like with credo) as opposed to at runtime because that could fail on production (not very with the “stability” Elixir ethos 😅).

Compile time would be better, but if you wanted to implement something like the check of GitHub issues then you’re adding HTTP requests to your application’s compile, which maybe means that you’re app doesn’t compile if the HTTP request fails (like because GitHub is down, even if the issue isn’t closed yet).

Chris McCord gives a deep history on Phoenix LiveView, going all the way back to the state of Ruby on Rails in 2013 up to the present. A 30-minute read! (LiveView-based uploads looks particularly interesting to me, since I’m rewriting how our uploads work at the moment.)

The latest Phoenix release ditches webpack and npm for esbuild and… nothing?

Of course, these are just the defaults — docs for Elixir’s esbuild clearly state that NPM is still supported and you can always pass --no-assets and do things 100% your way. But it’s easy to underestimate the power of defaults, especially those that cover area outside of target audience’s expertise — which is the case of Phoenix devs and JS bundlers.

In this post, the author lays out how they stitched together an esbuild + npm setup that will likely scale alongside the frontend of your application. I will surely be trying this setup on our app over the next few weeks and might even video it if you’re interested in going along for the ride.

Alex Koutmos:

If you follow my blog, you have probably noticed that my articles usually revolve around some deep technical problems and how to go about solving these problems using the amazing Elixir programming language. These posts usually discuss the technical merits surrounding Elixir and the Erlang virtual machine, but rarely touch on the “human” aspects of Elixir.

The goal of today’s post will be to address some of the non-technical aspects of the Elixir programming language and talk about the profound impact they can have on your engineers and your business. I’ll start off by addressing one of the most common concerns I come across when it comes to Elixir - that being that “It is hard to find Elixir developers”.

An excellent goal for a blog post. I’d love to see more like this for each and every sub-community in the software world.

This week on Ship It! Gerhard talks with Lars Wikman (independent Elixir/BEAM software consultant) why sometimes a monolith running on a single host with continuous backups and a built-in self-restore capability is everything that a small team of developers needs. That’s right, no Kubernetes or microservices. After 2 years of running changelog.com, a Phoenix monolith, on Kubernetes, what do I think? Join our discuss and find out!