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":
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.
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.
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
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)
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.
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.
> 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
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?
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...
https://blog.stenmans.org/theBeamBook/
Interesting. I wonder if there a world where Elixir starts compiling maps to "native records"?
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
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.