Erlang/OTP 29.0 | Hacker News Reader

Erlang/OTP 29.0

erlang.org

257 pointspyinstallwoes61 comments

Looks like a nice set of improvements. Disabling the SSH daemon [0] by default is a good security change, same with disabling the SFTP by default.

I think the io_ansi [1] module sounds pretty cool, imo erlang doesn't have a great story for building complicated CLI applications right now, but I haven't tried much. I imagine having this in the stdlib will be a nice leg up in the future. The way fwrite works seamlessly across nodes is very nice, and exactly what I love to see from erlang.

The addition of Native Records [2] is really cool. I'm curious how this will be leveraged in Elixir in the future, since right now I think there is a mix of records, tuples, and maps depending on exactly what is being done. Like the EEP says, I doubt we'll ever see the old records deprecated entirely but this looks like a substantial improvement.

[0] https://www.erlang.org/doc/apps/ssh/ssh.html

[1] https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html

[2] https://github.com/erlang/eep/pull/81

I don't think the ssh daemon was ever automatically enabled or started. The two bullet points are phrased differently, but I think they mean the same thing, when starting the ssh daemon, the listed parts won't be started by default.

> The SSH daemon now defaults to disabled for shell and exec services, implementing the “secure by default” principle. This prevents authenticated users from executing arbitrary Erlang code unless explicitly configured.

> The SFTP subsystem is no longer enabled by default when starting an SSH daemon.

For anyone wondering what the "OTP" part is in Erlang/OTP, it is a set of libraries and associated principles that, in effect, standardize the creation of highly reliable, fault-tolerant applications, originally for the telecom domain. It's worth checking out the brief introduction to the fundamental ideas in the introduction to "OTP Design Principles":

https://www.erlang.org/doc/system/design_principles.html

OTP = Open Telecom Platform

"Outlaw Techno Psychobitch"

https://www.youtube.com/watch?v=rRbY3TMUcgQ

And then Elixir was born!

I swear there's a video of Joe Armstrong et al. presenting part of this on stage and laughing along with it. I tried to find it last week but couldn't figure out which talk it was. A few years ago I think I watched every Erlang/OTP talk in existence.

no longer. That is legacy. OTP now just stands for "OTP"

It's still referred as such through the official documentation: https://www.erlang.org/faq/introduction.html#idm24

You may be thinking of comments like: https://erlangforums.com/t/should-otp-be-the-standard-librar...

You might want to update prod apps ASAP to this or the latest point version if below 29. Just deployed an app to production, automated security scans found 2 CRITICAL CVEs and half a dozen of HIGH risk ones dated Feb-May 2026.

Do you have a list?

Copied from the defectdojo report (generated on an Elixir 1.19 app on ubuntu noble base image from February 2026):

  Critical CVE-2025-32433 in erlang:27.3
  Critical CVE-2026-28808 in erlang:27.3   
  High CVE-2026-23941 in erlang:27.3 
  High CVE-2026-32144 in erlang:27.3   
  High CVE-2025-48041 in erlang:27.3   
  High CVE-2025-68973 in gpgv:2.4.4-2ubuntu17   
  High CVE-2025-30211 in erlang:27.3
  High CVE-2025-68973 GPGV 2.4.4-2ubuntu17

All these seem to be fixed by upgrading to latest ubuntu image + Erlang/OTP 28.5

Thank you. The problem with new OTP releases is that usually there's a X.0.1 release shortly after because something was broken. At least it was that way with 28. I'll wait a few weeks.

Is anyone still using Erlang for green field projects?

I know there are plenty of Elixir enthusiasts here, I mean plain ol' Erlang.

If you are still using Erlang, why do you prefer it to Elixir?

Yes, this year alone

- New IOT thing on atomvm.

- Application server written in erlang.

- TUI framework (still WIP).

Why do you prefer it to Elixir:

- Elixir doesn't pose any real advantage for me over erlang, i'm sure there may be be some, but it fits my brain easier. I'd probably even love to make it a social event to learn/get help, but I never seem to find anything that suits.

Can you provide some links? The IoT thing sounds interesting in particular.

I dox myself:

IOT basic (I have more sensors uncommited, but thats the basic outline )

- https://github.com/wmealing/limestone

My TUI framework (still a long way to go).

- https://github.com/wmealing/cellium

Can someone please explain the innards?

Innards of which part? The BEAM Book may be of interest to you:

https://blog.stenmans.org/theBeamBook/

I'm interested to see how records play out in the ecosystem.

I was about to say "what, we've had records for decades" but then I read the changelog.

Interesting. I wonder if there a world where Elixir starts compiling maps to "native records"?

Probably going to be replacement rather than direct recompilement of structs. I imagine all sorts of corner cases are lurking around if you swap implementation around, e.g. if someone force-pushed unknown key into a struct at runtime. Would be nice to keep current struct syntax though with the only difference in declaration

probably not maps, but structs yes.

I dunno… it’d break a looooot of code if structs were suddenly not also maps. My bet is this becomes a new option you have to manually migrate to.

Would it? I bet you could be very clever with transitional guards and the patching compiler to defensively handle both cases on detection of %{...}

Does anyone knows if WhatsApp is still based on Erlang?

Yes.

I’ve been using Erlang since the early 2010s, right around the time we (the tech industry) discovered that WhatsApp was supporting over 400 million active users with only like 30 engineers.

I reached out to one of their engineers at the time (when I still lived in the US) who kindly responded to some of my questions via email. We ended up meeting for coffee and still stay in touch to this day.

I can tell you that Erlang is still very much a part of WhatsApp.

I don't think we ever got an actual figure but I often wonder how many of those 30 engineers were actually using Erlang, i expect most of them are iOS and Android engineers.

Ok so this [1] is the December 2013 blog with 400 million monthly actives and 50 employees.

I don't have access to anything anymore, but 30 engineers sounds about right.

At that time, I think was about Two on Nokia S40, two on S60, two on Blackberry, two on WP. I think three on Android, three on iOS. One or two on voip (shhh, it won't be out until summer 2014). I probably missed one or two people that floated around different client projects.

So, something like 17 on server?; we were not a 100% Erlang shop of course (our web page was just PHP, our blog was still Wordpress at that time (hiss), but I can only think of onen server person who wasn't doing much in Erlang.

There were also a lot of people wearing many hats. Several client team members had significant contributions to server work and some work the other way too.

Try as I might, I never did convince the S40 team to run Erjang though.

[1] https://blog.whatsapp.com/400-million-stories

I don't have first hand knowledge (I left in 2019), but WhatsApp's public Erlang related repos are still active, and afaik, Erlang didn't escape into Meta at large, so if WA had moved off, there's no sense working on Erlang after that.

It is (source, old employee of me now works for them)

I think it's pretty likely they are since they gave a talk at Code BEAM Europe 2025: https://www.youtube.com/watch?v=tC435RGwRCI

Yes, erlang and increasingly rust

      Added support for -unsafe attributes

Right in time for the Rust rewrite! /s

Who even uses Erlang? I used Rails and then i tried Phoenix and it was lot more difficult to get things done.

I don't understand Phoenix hype

For solo devs, Rails is arguably most productive webapp system. LLM is very good at writing ruby rails code. Much better than writing django in my experience even though python training corpus is huge.

I write my experimental apps in Rail when it stabilizes, i do a Go rewrite.

I don't write directly in Go because, it consumes lot more token when the app scope is unknown but it's very efficient for rails.

These day i don't need react or angular anymore, i use Hotwire in Rails and HTMX in Go.

Erlang forum itself uses Discourse (written in Rails)

I’ve been writing Elixir apps full time since 2016. Clients are very, very happy never to see a crash. In fact, all the applications I have deployed in production in the past 10 years have 100% uptime. (Apart from hardware, OS and network faults outside my control)

You might want to broaden your horizons.

hello,

would you please recommend a good resource to get started with elixir ?

thanks for your time !

This is a good place to start:

https://elixirisallyouneed.dev/resources

This is a good list. I started with the books by Saša Jurić (they are excellent), and the Programming Phoenix LiveView is a must have if you want to do anything web-related.

If you're on the fence, this'll convince you: https://www.youtube.com/watch?v=JvBT4XBdoUE

I'd say Rails is faster than Phoenix (as in development speed) only for the first day or so. After that you'll stumble upon impicit logic, method-missing and this kind of stuff, which will require more time to figure out how it works. Elixi/Phoenix is more exlicit in that regard, making long-term support (as in anything past first week) a breeze. No hidden state, no figuring out where ModuleName.method(params) is coming from, no need to setup stuff to launch said method (just pass right arguments). The only downside i see is smaller library of ready to use packages

but if you want explicit any not just use django?

Elixir and Phoenix is a better production platform than Django.. I’m not throwing shade on Django, many production systems use it happily. I’m saying that Phoenix/Elixir is better, partly because of the BEAM and OTP and partly because of the language and the framework. Real concurrency. Better performance. Far more robust in production. The language is pre-compiled, and while not statically typed, that alone provides one more safety layer. It’s functional, which avoids a lot of the ugly patterns in both Rails and Django. It has a built-in fast and reliable KV store. It has distribution between the nodes if you want it (e.g. for a distributed cache). It enables you to debug with a remote shell connected live to the running system. There’s a lot more than I can add here.

if you want true concurrency, why not use goroutines? It provides single binary deployment and static types?

I am a Go dev, too. I consider Go my main language. The BEAM has a very, very similar architecture to the M:N scheduler in Go. Goroutines are not dissimilar to BEAM processes. You can similarly run thousands of processes on the BEAM. But Go does not have a real Phoenix equivalent and there are reasons to use Elixir and BEAM, especially on the web side, including some of what I already mentioned above.

Elixir is very ergonomic when it comes to concurrency, e.g. parallel-map example:

    1..10
    |> Task.async_stream(fn x -> x*2 end, max_concurrency: 2, timeout: 7000, on_timeout: :kill_task)
    |> Enum.to_list()

Equivalent Go code would be very long and very ugly.

Golang has its positives but you also lose a lot. Whole ecosystem is not comparable, like "debug live production cluster" is one-command away for Elixir vs "fuck you" for Golang

Django is not very different than Rails and imo much less ergonomic. Many issues are still there like hidden state/setup needed to call something

django requires more boilerplate and is less magic than rails.

Would you like to take a guess what the Ruby Discord uses?

Phoenix is mostly interesting because of OTP and channels (and LiveView I guess but it's not a choice I would make in 2026) so if you don't need what they bring...

Ecto is not bad as well.

Claude Code is very good at writing Elixir.

Surprise, you'll be more productive with what you know, LLM or not.

Is your disinterest in LiveView because you'd prefer the more common SPA/API separation, or some other reason? I'm curious because as a mostly backend engineer I view LiveView as sort of a killer tool for the sorts of apps or tools I'm likely to build.

Not the parent, but since the liveview state is on the server side it means that one server can't support a large number of concurrent sessions, for some value of large.

I just strongly dislike the layout engine ;) Also yeah deployment with active socket connections is not always ideal.

Not writing api routes for the frontend (when you don't also have a mobile app etc) is nice though, and pairing it with PubSub for UI updates is a cool trick.

I used both Rails and Phoenix.

ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO, but not everyone shares the same feeling.

Despite having built in concurrency my team ended up building a version of Sidekiq because supervisors don't cover all use cases of job control.

I prefer deploying with Capistrano than with Elixir builds. Another matter of taste.

Structural pattern matching is the only feature I dearly miss, but that's a feature of the language.

We never used Liveview. We had a backend for a JSON API so I can't compare that feature.

> ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO

A stateful mechanism vs a data mapper? Absolutely not. Being able to write `user.save()` is such a lunacy, thank god we have functional languages that (necessarily) decouple storage from data models.

I cringe every time I have to use imperative, stateful languages.

> ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO, but not everyone shares the same feeling.

Well, depends on what you do. Ecto is closely follows SQL logic and allows to translate weird sql queries into code directly. All queries are explicit, e.g. you either do preload(...) or can't access nested records at all, no chance of N+1 by design.

Changesets are also different and are just functions you can define as needed.

    defmodule MyApp.User do
    ...
    def changeset(user, attrs) do
        user
        |> cast(attrs, [:email])
        |> validate_required([:email])
        # This matches the error from the DB uniq index to the :email field
        |> unique_constraint(:email)
    end

It's fun watching other languages orms be 10 years behind in design.

Your example is a common anti pattern from PHP orms 15 years ago.

1) that's not an ORM

2) after ~8 years of using it, i find it ergonomic, light on congitive load and good for long term support

Calling it not an ORM just cause it implements a DTO is splitting hairs. It's an ORM. If you are hydrating an object that saves to storage and you are manipulating it's life cycle and then casting types between your storage primitives and your language primitives from memory to disk you are writing code that every other ORM is writing and it's not special.

As soon as you add use Ecto.Schema to your model it's an ORM.

> But it doesn't require a database and queries have to be explicit!

yea yea that's a feature of every ORM

Could be wrong, but i dont think thats an orm.

> I don't write directly in Go because, it consumes lot more token when the app scope is unknown but it's very efficient for rails.

The absolute irony of writing this whole ramble and then revealing that you're not even the one writing the code.

Erlang != Elixir - but otherwise a good question. I think WhatsApp uses erlang

I write Rails aswell but comparing Rails with Erlang is kinda weird, they are for completely different domains. Both can co-exist in this world. These are only tools, not a cult or part of personality.

Reply on news.ycombinator.com