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.
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":
- 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.
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.
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.
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
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.
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.
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)
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.
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
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.
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
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.
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.
> 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
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!
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.
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
> 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.
https://www.erlang.org/doc/system/design_principles.html
https://www.youtube.com/watch?v=rRbY3TMUcgQ
You may be thinking of comments like: https://erlangforums.com/t/should-otp-be-the-standard-librar...
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?
- 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.
https://blog.stenmans.org/theBeamBook/
Interesting. I wonder if there a world where Elixir starts compiling maps to "native records"?
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 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)
You might want to broaden your horizons.
would you please recommend a good resource to get started with elixir ?
thanks for your time !
https://elixirisallyouneed.dev/resources
If you're on the fence, this'll convince you: https://www.youtube.com/watch?v=JvBT4XBdoUE
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
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.
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.
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.
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.
Your example is a common anti pattern from PHP orms 15 years ago.
2) after ~8 years of using it, i find it ergonomic, light on congitive load and good for long term support
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