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":
Does anyone knows if WhatsApp is still based on Erlang?
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
no longer. That is legacy. OTP now just stands for "OTP"
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 not maps, but structs yes.
Can someone please explain the innards?
Innards of which part? The BEAM Book may be of interest to you:
https://blog.stenmans.org/theBeamBook/