OTP26 - Would you use it already?


I’m trying to decide on an OTP version for a new project.

Would you say OTP26 is a good choice at this point? By that I mean supported broadly in the eco system and with limited head scratching “why does x -which used to work so well for me in the past- no longer work”?

Thank you!

1 Like

If you are starting a new project, you might as well start with the latest versions of OTP and Elixir, because it’s unlikely that in the future we’ll move back to older versions of OTP :wink:


It seems the FreeBSD package of Erlang only supports OTP 25. Maybe there are some issue to be fixed.

I would recommend to use rtx or asdf to manage elixir/erlang versions to avoid having problems with dependencies, OTP-26 is present there.


I remember some issues in the very first few patch releases but nobody is mentioning them lately so I am pretty sure that installing OTP 26.1 is safe nowadays.


Thank you all for the thoughts :+1:

I ended up going with OTP 24, as it turned out that is the version of the official package for Ubuntu 22.04.

I was trying to go a bit more ‘up to date’, but Erlang Solutions’ pre-built packages seem to have certificate problems (at least for me). I try to avoid asdf, etc, as I like to stay close to the source of things, where possible. Building from source would be a viable alternative, though.

Installing Elixir was a bit more complicated, as the official Elixir package on Ubuntu 22.04 is 1.12, which is too low for Phoenix. So I used the official pre-compiled packages from the Elixir Github releases page. Unzip, add to path, done.

It would be so nice (and a great developer experience), if the Elixir package on Ubuntu was at least the version Phoenix needs… But it’s probably not trivial to get an official Ubuntu package updated…

The official docker erlang image hasn’t been manually updated (as is required for every release) to the latest OTP version yet. The hexpm images are fine as always though.

That’s exactly what asdf and rtx do (I recommend rtx). They build from source.

There’s no need to be conservative about using version managers. They fill a much-needed niche.


This is a part of my Dockerfile. You can find the URLs of the sources codes.

# Install Erlang
RUN mkdir -p otp && \
    curl -LS "https://github.com/erlang/otp/releases/download/OTP-${OTP_VERSION}/otp_src_${OTP_VERSION}.tar.gz" --output otp.tar.gz && \
    tar xfz otp.tar.gz -C otp --strip-components=1
WORKDIR /tmp/otp
RUN ./configure && make && make install

# Install Elixir
RUN mkdir -p elixir && \
    curl -LS "https://github.com/elixir-lang/elixir/archive/v${ELIXIR_VERSION}.tar.gz" --output elixir.tar.gz && \
    tar xfz elixir.tar.gz -C elixir --strip-components=1
WORKDIR /tmp/elixir
RUN make install -e PATH="${PATH}:/usr/local/bin"

Or you can use HexPM’s Docker image.


Thanks for the Docker tips!

Re asdf: Maybe it’s silly, but I’m always a bit worried that somebody might be able to slip a commit in that does something naughty. I say this based on what I see in the npm world…

Asdf contains no actual packages on their repos, it just downloads them straight from github and compiles them from source.

1 Like

Kerl and therefore asdf do backport certain compatibility patches though. It’s not necessarily straight github to compilation.

1 Like

That goes for every single software on the planet. If you have such reservations relating to version managers then you should have them towards all programs everywhere.

You don’t know for a fact that ls or rm don’t collect telemetry somewhere and then send it off-site when your screensaver activates.

It’s a huge rabbit hole.

So yeah, your reservations are silly alright.