Elixir 1.19

• Versi Elixir 1.19 memungkinkan lebih banyak bug terdeteksi lebih cepat melalui penguatan sistem tipe dan peningkatan performa kompilasi
• Inferensi tipe kini diperluas hingga fungsi anonim dan protokol, sehingga validasi otomatis yang lebih luas dapat dilakukan tanpa anotasi tipe dari pengguna
• Pada proyek besar, versi ini menghadirkan kecepatan kompilasi hingga 4 kali lebih cepat, termasuk optimasi kompilasi paralel dan pemuatan kode
• Dukungan Erlang/OTP 28, adopsi sertifikasi OpenChain, dan penguatan transparansi rantai pasok dalam ekosistem juga ditambahkan
• Selain itu, rilis ini juga mencakup berbagai fitur seperti peningkatan parsing opsi, peningkatan kemampuan debug ExUnit, dan peningkatan aksesibilitas dokumentasi berbasis shell

---

Peningkatan utama di Elixir 1.19

Peningkatan sistem tipe

Inferensi tipe untuk semua komponen

• Type inference (inferensi tipe) adalah fitur untuk menentukan tipe ekspresi secara otomatis pada saat kompilasi
• Sebelumnya, inferensi tipe terutama ditujukan untuk pola, guard, dan nilai kembalian, tetapi pada rilis ini diperkenalkan inferensi tipe untuk semua komponen (kecuali guard)
• Karena tipe diinferensikan dengan merujuk juga ke dalam modul dan pemanggilan fungsi pustaka standar Elixir, fungsi yang sebelumnya diinferensikan sebagai dynamic() -> boolean() kini dapat diinferensikan lebih jelas seperti integer() -> boolean()
• Inferensi tipe melibatkan berbagai trade-off seperti kecepatan kompilasi, daya ekspresif, kompilasi bertahap, dan kejelasan error, sehingga ke depannya akan ditambahkan inferensi tipe guard serta informasi tipe dependensi
• Jika fungsi memiliki signature tipe yang dinyatakan secara eksplisit, maka yang berlaku bukan inferensi tipe melainkan pemeriksaan tipe eksplisit, sehingga hanya tipe yang sesuai dengan anotasi pengguna yang diizinkan

Pemeriksaan tipe saat dispatch dan implementasi protokol

• Elixir kini menerapkan pemeriksaan tipe saat pemanggilan dan implementasi protokol
• Misalnya, jika tipe yang tidak mengimplementasikan protokol String.Chars diberikan ke interpolasi string, maka akan muncul pesan peringatan
• Pada for comprehension, jika tipe yang tidak memenuhi protokol Enumerable diberikan sebagai generator, peringatan juga akan muncul
• Pemeriksaan tipe ini memungkinkan lebih banyak bug dicegah pada saat kompilasi

Inferensi dan pemeriksaan tipe untuk fungsi anonim

• Elixir 1.19 mendukung inferensi tipe dan pemeriksaan tipe untuk fungsi anonim
• Sebagai contoh, jika tipe yang salah seperti "hello" diberikan ke fungsi anonim yang mengharapkan tipe %{}, hal itu dapat langsung dideteksi sebagai peringatan saat kompilasi
• Inferensi tipe juga diterapkan pada function capture (&String.to_integer/1 dan sebagainya), sehingga cakupan validasi tipe otomatis menjadi lebih luas

Referensi dan mitra

• Sistem tipe ini dikembangkan melalui kemitraan antara CNRS dan Remote
• Fresha, *Starfish* *, Dashbit, dan lainnya turut mendukung

Kecepatan kompilasi yang lebih cepat pada proyek besar

Perbaikan bottleneck pemuatan kode

• Sebelumnya, modul langsung dimuat begitu didefinisikan, tetapi pada rilis ini strategi tersebut diubah menjadi lazy loading (pemuatan tertunda)
• Dengan perubahan ini, beban pada code server berkurang dan performa kompilasi paralel meningkat, sehingga kecepatan kompilasi proyek besar menjadi lebih dari 2 kali lebih cepat
• Dua hal penting yang perlu diperhatikan
  • Jika selama kompilasi membuat proses terpisah lalu mengakses modul dalam proyek yang sama, pemuatan bisa terlewat; untuk mengatasinya gunakan Kernel.ParallelCompiler.pmap/2 atau Code.ensure_compiled!/1
  • Di dalam callback @on_load, pemanggilan modul dalam proyek yang sama dapat menimbulkan error; bila perlu gunakan opsi @compile {:autoload, true}
• Pada kedua kasus tersebut, sebelumnya dapat muncul error kompilasi yang non-deterministik, tetapi dengan perbaikan kali ini lingkungan kompilasi yang deterministik (dapat direproduksi) dapat dijamin

Kompilasi paralel dependensi

• Dengan memanfaatkan variabel lingkungan MIX_OS_DEPS_COMPILE_PARTITION_COUNT, kini didukung kompilasi paralel dependensi
• Karena dependensi dikompilasi secara paralel menggunakan beberapa proses OS sekaligus, performa kompilasi dapat meningkat hingga 4 kali tergantung skala proyek dan jumlah core CPU
• Secara eksperimental, menetapkan nilai sekitar setengah dari total core efektif untuk pemanfaatan sumber daya
• Karena paralelisasi dapat meningkatkan penggunaan memori, perlu kehati-hatian saat menerapkannya di CI atau server build

Dukungan Erlang/OTP 28

• Elixir 1.19 secara resmi mendukung Erlang/OTP 28.1+
• Seiring perubahan representasi regular expression di Erlang/OTP 28, regular expression tidak lagi bisa digunakan sebagai nilai default struct
• Saat inisialisasi struct, regular expression tetap dapat digunakan

Adopsi sertifikasi OpenChain

• Rilis ini adalah versi pertama yang mulai mematuhi spesifikasi OpenChain
• Setiap rilis menyertakan SBoM (Source Bill of Materials) dalam format CycloneDX 1.6/SPDX 2.3
• Hal ini meningkatkan transparansi rantai pasok atas komponen rilis dan lisensi, serta membantu pengelolaan yang lebih ketat
• Pekerjaan ini dikerjakan oleh Jonatan Männchen dan didukung oleh Erlang Ecosystem Foundation

Peningkatan lainnya

• Berbagai peningkatan alat dan pustaka juga ditambahkan, termasuk parsing opsi, debug dan performa ExUnit, serta aksesibilitas dokumentasi berbasis shell
• Untuk catatan rilis yang lebih rinci, lihat CHANGELOG

[GN⁺]

Pendapat Hacker News

• Ditekankan bahwa cara Elixir memperkenalkan fitur pemeriksaan tipe otomatis secara bertahap adalah contoh peningkatan bahasa yang sangat baik dan layak dijadikan acuan oleh bahasa pemrograman lain. Sudah banyak contoh bahasa yang ekosistemnya terbelah dua akibat perubahan besar, dan José sendiri sudah dengan jelas menyatakan sejak 2018 bahwa bahasanya pada dasarnya sudah selesai, sehingga terasa menenangkan. Dijelaskan juga bahwa bahasa dan core-nya tidak akan berubah secara merusak lagi, yang memberi rasa stabilitas besar. Merekomendasikan video presentasi terkait. Sangat terkesan dengan pengelolaan yang konsisten dan sangat baik.

  • Dari bahasa-bahasa utama, contoh perpecahan ekosistem akibat perubahan besar yang terpikir hanya Python 3 dan Perl 6. Karena perubahan keduanya begitu mengguncang, perubahan pada bahasa lain pun jadi terasa sangat besar.
  • Di Elixir, tidak pernah terasa seperti selalu dikejar-kejar untuk upgrade versi. Justru sambil melihat perubahan yang masuk, muncul keinginan untuk upgrade karena ada fitur baru yang benar-benar berguna. Tidak terasa cemas atau stres seperti saat dipaksa pindah versi seolah-olah sedang diseret.
  • Sudah memakai Elixir di lingkungan production sejak 2017, dan setiap kali upgrade, prosesnya selalu jauh lebih mulus daripada yang diperkirakan. Justru upgrade Erlang/OTP sering kali lebih rumit karena masalah kompatibilitas, jadi biasanya tetap memakai Elixir terbaru tetapi menunggu satu atau dua bulan lagi untuk versi OTP sampai potensi konflik sudah dibereskan sebelum ikut di-upgrade.
  • Elixir masih terasa agak kurang matang dan kurang nyaman dipakai, sehingga dibutuhkan panduan yang jelas untuk mencapai tujuan tertentu serta stabilisasi ekosistem. Banyak package terbengkalai atau dokumentasinya kurang, sehingga sulit mengikuti cepatnya perubahan ekosistem Phoenix. Banyak juga pengguna yang tidak menginginkan LiveViews atau sistem komponen tertentu, dan hambatan masuk untuk kompatibilitas dengan tool dan teknologi lain juga tinggi. Python 3 memang harus berpindah dari 2 ke 3, dan relatif berhasil berkat tool migrasi otomatis, meski tetap banyak trial and error. Sebaliknya, Ruby 3 justru menimbulkan kebingungan dengan pengenalan file tipe eksternal dan perpecahan tool, ditambah pengalaman negatif seperti boilerplate, masalah governance, dan pembajakan gem, sehingga jadi jarang memakai Ruby lagi. Ditekankan bahwa bahkan bahasa yang hebat pun bisa rusak total karena pengelolaan yang belum matang, jadi kolaborasi dan komunikasi yang dewasa serta manajemen perubahan yang baik sangat penting. Perubahan desain bahasa seharusnya didahului eksperimen yang cukup dan kehati-hatian, serta diberi penjelasan yang memadai kepada pengguna sejak awal agar kebingungan yang tidak perlu bisa diminimalkan. Berharap Elixir/Phoenix/OTP ke depan menjadi lebih mudah, lebih kuat, lebih produktif, dan performanya makin baik sehingga beragam pengguna bisa memakainya dengan tenang. Merekomendasikan sumber seperti Livebook dan Exercism Elixir track.

• Elixir terus menghadirkan fitur dan peningkatan yang hebat secara konsisten sambil berkembang dengan stabil. Struktur bahasanya luar biasa, dan para pembuatnya terus menjaga arah yang benar, yang benar-benar mengesankan. Justru yang disayangkan adalah tidak adanya kesempatan memakai Elixir dalam keseharian.

  • Karena ingin memakai Elixir, sampai keluar dari perusahaan lalu mendirikan startup sendiri.

• Membagikan data eksperimen terkait kecepatan kompilasi dependency Phoenix. Di Mac M1 Max, berdasarkan aplikasi kecil yang hanya berisi dependency Phoenix bawaan, waktu kompilasi berikut diukur menurut nilai environment variable MIX_OS_DEPS_COMPILE_PARTITION_COUNT.

  PARTITION_COUNT=1:  12.336초 (유저 32.30s, 시스템 7.23s, CPU 320%)
  PARTITION_COUNT=5:  6.970초 (유저 0.37s, 시스템 0.49s, CPU 12%)
  PARTITION_COUNT=10: 7.236초 (유저 0.38s, 시스템 0.50s, CPU 12%)
  

  Cache dibersihkan setiap kali di tengah pengujian dengan perintah rm -rf _build.

  • Kemungkinan eksekusi setelahnya diukur saat cache sudah diterapkan, dan mungkin kompilasi native dilakukan langsung di folder dep sehingga tidak meninggalkan jejak di _build.
  • Tidak paham mengapa hasil benchmark untuk fitur di rilis ini mendapat downvote, dan bertanya apakah ada yang bisa menjelaskan pendapatnya.

• Dalam beberapa bulan terakhir benar-benar jadi sangat menyukai Gleam. Menyambut baik masuknya sistem tipe ke Elixir, tetapi dulu hal ini adalah salah satu faktor utama yang membuat Elixir sulit diadopsi. Ingin suatu saat mencoba Elixir lagi, tetapi khawatir jangan-jangan seperti TypeScript di JavaScript: secara tampilan bertipe, tetapi pada praktiknya banyak lib atau package yang akhirnya hanya menjadi dynamic/any. Bertanya apakah kekhawatiran ini tidak beralasan. Beam memang luar biasa.

  • Kondisinya berbeda dari TypeScript. Berkat pattern matching, codebase Elixir yang sudah ada pun tampaknya bisa mendapat type inference setidaknya sekitar 50%, dan karena vanilla Elixir menyediakan tipe secara bawaan, code yang dipelihara akan cepat bergerak menuju pengetikan tipe. Saya pribadi tidak menyukai sistem tipe dan hanya memakai JS, tetapi pada Elixir penerapan tipe terasa alami. TypeScript bergerak ke atas, sementara Elixir menyebar ke bawah secara alami.
  • Gleam tidak bisa sepenuhnya memanfaatkan kekuatan sejati OTP/BEAM. Itu adalah daya tarik yang hanya diberikan Elixir.
  • Elixir sejak dulu sudah memiliki konsep tipe seperti primitive type, struct, dan destructuring berbasis shape, dan pemeriksaan tipe juga dimungkinkan dengan tool seperti Dialyzer dan TypedStruct. Ini bukan bahasa tanpa tipe yang absurd seperti JavaScript.
  • Gleam juga bagus, tetapi di JVM ada Kotlin, bahasa bertipe dengan sintaks mirip Ruby, dan bisa juga compile-to-JS.

• Elixir terasa sebagai salah satu lingkungan pengembangan web yang paling menjanjikan. Setiap kali bertemu organisasi atau tim yang memakai Elixir di dunia kerja nyata, kualitas mereka tampak lebih tinggi daripada rata-rata. Dalam lingkungan yang membutuhkan pengembangan berkelanjutan, Elixir dinilai terus menghadirkan arah dan standar yang jelas.

• Diperkenalkan bahwa rilis Elixir mulai mendukung format Source SBoM untuk CycloneDX 1.6 ke atas dan SPDX 2.3 ke atas. Sangat patut disyukuri bahwa pengelolaan SBOM dilakukan di tingkat bahasa. Sayangnya saat ini perusahaan tersebut tidak memakai Elixir.

• Jika ingin berkontribusi ke proyek Elixir open source yang benar-benar dipakai, komponen utama bekas Mozilla Hubs masih terus dikembangkan sebagai proyek independen dengan Elixir. Lihat Hubs Foundation/reticulum.

• Berdasarkan standard library Elixir, type inference pada compile time dimungkinkan sesuai konteks spesifik aplikasi, misalnya dari dynamic ke boolean, atau dari integer ke boolean.

• Belum punya pengalaman mengembangkan dengan Elixir, tetapi tetap penggemar. Dulu menyukai kepraktisan dan keindahan Ruby, tetapi kemudian berpindah bahasa setelah tertarik pada sistem tipe. Elixir dan Ruby sama-sama memperkenalkan sistem tipe, tetapi sekarang lebih banyak memakai Kotlin yang secara sintaks terasa seperti "Ruby yang sudah diberi tipe".

  • Kotlin hampir seperti wujud jruby yang benar-benar kita inginkan.

• Sedang memakai Soketi yang terhubung dengan pusher sdk untuk menangani broadcast event. Struktur aplikasi mencampur endpoint real-time dan endpoint rest, dan beban komputasi real-time tidak terlalu besar, tetapi jika perlu berencana menanganinya terpisah dengan Go. Fitur kolaborasi juga akan segera ditambahkan, dan sedang mempertimbangkan apakah masuk akal mengadopsi Phoenix dalam situasi seperti ini.