Erlang/OTP 29.0

• SSH daemon kini menonaktifkan layanan shell dan exec secara default, sehingga tanpa konfigurasi eksplisit, pengguna yang telah terautentikasi tidak dapat menjalankan kode Erlang arbitrer
• Saat memulai SSH daemon, subsystem SFTP juga tidak lagi diaktifkan secara default, sehingga default keamanan diperkuat
• Atribut -unsafe ditambahkan agar fungsi yang tidak aman bisa ditandai, dan compiler secara default menghasilkan peringatan untuk pemanggilan fungsi yang di Erlang/OTP diketahui selalu tidak aman
• xref kini dapat menemukan pemanggilan fungsi yang tidak aman dan fungsi tanpa dokumentasi, serta pemfilteran atribut ignore_xref diubah agar ditangani oleh xref itu sendiri
• Dalam konfigurasi default SSL, x25519mlkem768 menjadi grup pertukaran kunci yang paling diprioritaskan, dan algoritme pertukaran kunci default SSH juga diubah menjadi mlkem768x25519-sha256, yang menggabungkan ML-KEM-768 dan X25519
• Pada code path default sistem Erlang, posisi direktori kerja saat ini . dipindahkan dari urutan pertama ke terakhir, sehingga urutan loading berubah
• Build Erlang/OTP 32-bit untuk Windows tidak lagi disediakan
• Native records dari EEP-79 telah diimplementasikan, dan di Erlang/OTP 29 dianggap sebagai fitur eksperimental
• Guard BIF is_integer/3, multi-value comprehension berbasis EEP 78, dan variable binding di dalam comprehension melalui fitur compr_assign telah ditambahkan
• Compiler menambahkan peringatan default untuk catch, mengekspor variabel ke luar subekspresi, and/or, serta pola match alias seperti {a,B} = {X,Y}, dan menyediakan opsi untuk menonaktifkan masing-masing
• Guard test lama dijadwalkan dihapus dari bahasa pada Erlang/OTP 30, dan peringatan penggunaan obsolete guard yang ada tetap berlaku
• Dengan io_ansi, ANSI/Virtual Terminal Sequence dapat dikeluarkan ke terminal, dan dengan ct_doctest, contoh dalam dokumentasi modul Erlang dan file dokumentasi dapat diuji

[GN⁺]

Komentar Hacker News

• Perbaikannya terlihat cukup bagus. Menonaktifkan daemon SSH secara default dan juga menonaktifkan SFTP secara default adalah perubahan yang baik dari sisi keamanan
  Modul io_ansi juga terlihat cukup keren. Saat ini Erlang belum terlalu punya banyak cerita bagus untuk membuat aplikasi command-line yang kompleks, jadi kalau ini masuk ke pustaka standar sepertinya akan sangat membantu ke depannya. Cara fwrite bekerja secara alami antar-node juga merupakan keunggulan yang memang diharapkan dari Erlang
  Penambahan Native Records juga menarik. Saat ini di Elixir terasa seperti record, tuple, dan map dipakai bercampur tergantung situasi, jadi saya penasaran bagaimana ini akan dimanfaatkan nanti. Seperti yang dikatakan di EEP, record lama sepertinya tidak akan dihapus sepenuhnya, tetapi ini tampak sebagai peningkatan yang cukup besar
  https://www.erlang.org/doc/apps/ssh/ssh.html
  https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
  https://github.com/erlang/eep/pull/81

  • Sepertinya daemon SSH memang tidak pernah aktif atau dimulai secara otomatis. Walau redaksi kedua poin itu berbeda, maknanya tampak bahwa saat memulai daemon SSH, komponen yang terdaftar tersebut tidak akan dijalankan secara default
    Daemon SSH sekarang menonaktifkan shell dan layanan exec secara default, mengikuti prinsip secure by default. Jika tidak dikonfigurasi secara eksplisit, ini mencegah pengguna yang sudah terautentikasi menjalankan kode Erlang sewenang-wenang
    Subsistem SFTP juga tidak lagi diaktifkan secara default saat daemon SSH dimulai

• Bagi yang penasaran apa arti OTP dalam Erlang/OTP, ini pada dasarnya adalah kumpulan pustaka dan prinsip yang awalnya dibuat untuk menstandarkan pembuatan aplikasi berkeandalan tinggi dan toleran terhadap kegagalan untuk bidang telekomunikasi
  Ide dasarnya layak dibaca sekilas di pengantar “OTP Design Principles”
  https://www.erlang.org/doc/system/design_principles.html

  • OTP = Open Telecom Platform

• Jika aplikasi produksi Anda masih di bawah 29, mungkin sebaiknya segera perbarui ke versi ini atau ke versi patch terbaru. Saya baru saja melakukan deploy ke produksi, dan pemindaian keamanan otomatis menangkap 2 CVE CRITICAL bertanggal Februari–Mei 2026 serta beberapa item berisiko HIGH

  • Ada daftarnya?

• Saya penasaran apakah masih ada orang yang memakai Erlang untuk proyek baru
  Saya tahu banyak orang di sini suka Elixir, tetapi yang saya maksud adalah Erlang murni
  Kalau Anda masih memakai Erlang, saya penasaran apa alasan Anda lebih memilihnya daripada Elixir

  • Bahkan tahun ini pun masih ada. Ada pekerjaan IoT baru berbasis AtomVM, server aplikasi yang ditulis dengan Erlang, dan framework TUI yang masih sedang dikerjakan
    Elixir tidak memberi saya keunggulan praktis dibanding Erlang. Tentu mungkin ada kelebihannya, tetapi Erlang lebih cocok dengan cara saya berpikir. Saya juga ingin mencoba belajar atau mencari bantuan lewat pertemuan sosial, tetapi sulit menemukan tempat yang cocok untuk saya

• Bisa ada yang menjelaskan struktur internalnya?

  • Itu tergantung bagian internal mana yang dimaksud. The BEAM Book mungkin menarik
    https://blog.stenmans.org/theBeamBook/

• Saya penasaran bagaimana record akan menemukan tempatnya dalam ekosistem

  • Saya tadinya mau bilang, “bukannya record sudah ada sejak puluhan tahun lalu?” lalu saya membaca changelog-nya
    Menarik. Saya penasaran apakah suatu hari Elixir akan mengompilasi map menjadi native records

• Ada yang tahu apakah WhatsApp masih berbasis Erlang?

  • Ya
    Mereka sudah memakai Erlang sejak awal 2010-an, dan sekitar masa itu industri teknologi mengetahui bahwa WhatsApp mendukung lebih dari 400 juta pengguna aktif hanya dengan sekitar 30 engineer
    Waktu itu saya menghubungi salah satu engineer di sana, dan saat saya masih tinggal di AS dia dengan baik hati menjawab beberapa pertanyaan lewat email. Pada akhirnya kami bahkan sempat minum kopi, dan kami masih berhubungan sampai sekarang
    Bisa dibilang Erlang masih menjadi bagian penting dari WhatsApp
  • Dari presentasi mereka di Code BEAM Europe 2025, kemungkinan besar masih begitu: https://www.youtube.com/watch?v=tC435RGwRCI
  • Saya tidak tahu langsung, tetapi saya pergi pada 2019, dan repo publik WhatsApp yang terkait Erlang masih aktif. Sepengetahuan saya, Erlang juga tidak menyebar ke seluruh Meta, jadi kalau WhatsApp sudah meninggalkan Erlang, tidak banyak alasan untuk terus mengerjakan hal-hal Erlang setelah itu
  • Ya. Mantan karyawan saya sekarang bekerja di sana
  • Ya. Mereka memakai Erlang dan Rust juga makin banyak dipakai

• Jadi ada dukungan untuk atribut -unsafe, waktu yang pas untuk rewrite ke Rust /s

• Saya benar-benar tidak tahu siapa yang memakai Erlang. Saya memakai Rails lalu mencoba Phoenix, dan rasanya jauh lebih sulit untuk benar-benar menyelesaikan sesuatu
  Saya tidak paham kenapa Phoenix begitu dipuja
  Untuk pengembang solo, Rails mungkin adalah sistem webapp paling produktif. LLM juga menulis kode Ruby on Rails dengan sangat baik. Walaupun korpus pelatihan Python sangat besar, menurut pengalaman saya hasilnya jauh lebih baik dibanding Django
  Saya menulis aplikasi eksperimental dengan Rails, lalu ketika sudah stabil saya rewrite ke Go. Kalau ruang lingkup aplikasi belum jelas dan langsung ditulis dengan Go, token yang terpakai jadi jauh lebih banyak, sedangkan dengan Rails sangat efisien
  Sekarang React atau Angular pun sudah tidak terlalu diperlukan lagi, di Rails saya pakai Hotwire dan di Go saya pakai HTMX
  Bahkan forum Erlang sendiri memakai Discourse yang ditulis dengan Rails

  • Sejak 2016 saya menulis aplikasi Elixir secara full-time. Klien sangat puas dengan tidak melihat crash. Faktanya, semua aplikasi yang saya deploy ke produksi selama 10 tahun terakhir mencatat uptime 100%. Tentu tidak termasuk kegagalan hardware, OS, atau jaringan yang di luar kendali saya
    Mungkin ada baiknya sedikit memperluas perspektif
  • Menurut saya Rails hanya lebih cepat daripada Phoenix kira-kira di hari pertama pengembangan. Setelah itu Anda mulai terbentur logika implisit, hal-hal seperti method_missing, dan justru menghabiskan lebih banyak waktu untuk memahami bagaimana semuanya bekerja
    Elixir/Phoenix lebih eksplisit dalam hal itu, jadi untuk pemeliharaan jangka panjang, yakni setelah melewati minggu pertama, jauh lebih nyaman. Tidak ada state tersembunyi, tidak perlu memburu dari mana ModuleName.method(params) berasal, dan tidak perlu menyiapkan sesuatu dulu untuk menjalankan metode tersebut; cukup berikan argumen yang benar. Kekurangannya paling hanya ekosistem paket siap pakai yang lebih kecil
  • Mau tebak Ruby Discord memakai apa?
  • Alasan utama Phoenix menarik adalah OTP, channel, dan LiveView. Namun saya rasa LiveView bukan pilihan yang akan saya ambil pada 2026, dan kalau Anda tidak membutuhkan fitur-fitur seperti itu, daya tariknya bisa berkurang
    Ecto juga lumayan bagus
    Claude Code menulis kode Elixir dengan sangat baik
    Yang agak mengejutkan, dengan atau tanpa LLM, orang memang lebih produktif saat memakai teknologi yang sudah mereka kuasai
  • Ada ironi mutlak dalam kalimat “kalau ruang lingkup aplikasi belum jelas dan langsung ditulis dengan Go, token yang terpakai jadi jauh lebih banyak, sedangkan dengan Rails sangat efisien.” Setelah bicara panjang lebar, ternyata Anda sendiri bahkan tidak menulis kodenya