Gleam OTP – Pengembangan Program Multicore Tahan Gangguan Berbasis Aktor

 (github.com/gleam-lang)
1 poin oleh GN⁺ 2025-10-21 | 1 komentar | Bagikan ke WhatsApp
  • Gleam OTP mendukung pengembangan program yang memanfaatkan model aktor untuk menghadirkan ketahanan terhadap kegagalan dan performa multicore
  • Fitur utamanya adalah menargetkan keamanan tipe penuh dan kompatibilitas dengan Erlang OTP
  • Menyediakan pemulihan saat terjadi kegagalan dan kemampuan self-healing melalui supervisor
  • Hanya menyediakan sebagian fitur Erlang/OTP, dan strategi manajemen tambahan saat ini masih dalam pengembangan
  • Mendukung berbagai tipe aktor seperti process umum, actor, dan supervisor

Gambaran Umum Gleam OTP

  • Gleam OTP adalah framework aktor yang kuat dan terinspirasi oleh arsitektur OTP milik Erlang, cocok untuk membangun program multicore yang tahan gangguan
  • Sebagai proyek open source, proyek ini menggunakan lisensi Apache-2.0

Fitur dan Keunggulan Utama

  • Menjamin keamanan tipe penuh untuk aktor dan pesan
  • Menyediakan kompatibilitas dengan Erlang OTP, sehingga mudah diintegrasikan dengan lingkungan Erlang yang sudah ada
  • Mendukung toleransi kegagalan melalui supervisor untuk deteksi gangguan, pemulihan otomatis, dan pengelolaan penghentian
  • Menargetkan performa setara dengan Erlang OTP
  • Menyediakan dokumentasi dan contoh sehingga mudah dipelajari dan diterapkan dalam praktik

Penjelasan per Tipe Aktor

  • Process

    • Berperan sebagai blok pembangun paling dasar di dalam OTP
    • Menjadi fondasi bagi tipe aktor lain, tetapi tidak sering digunakan secara langsung dalam aplikasi Gleam

  • Actor

    • Tipe process yang paling umum digunakan, dengan fungsi yang mirip gen_server di Erlang
    • Menangani pesan sistem OTP secara otomatis serta mengaktifkan fitur debugging dan tracing

  • Supervisor

    • Bertugas memulai process lain serta mengawasi dan memulihkannya
    • Process anak akan otomatis dijalankan ulang saat terjadi crash atau kondisi pengecualian
    • Melalui struktur supervisor bertingkat (supervision tree), aplikasi dapat membentuk arsitektur tahan gangguan
    • Detail implementasi dapat dilihat pada dokumentasi gleam/otp/static_supervisor dan gleam/otp/factory_supervisor

Keterbatasan dan Isu

  • Saat ini actor belum mendukung semua pesan sistem OTP, dan pesan yang belum didukung akan diabaikan
  • Beberapa fitur API debugging OTP masih terbatas
  • Jika diperlukan, dukungan untuk pesan yang belum diimplementasikan dapat diminta dengan membuat issue

Kesimpulan dan Pentingnya Proyek

  • Gleam OTP memperluas kekuatan ekosistem Erlang ke bahasa Gleam, sehingga keamanan tipe dan ketahanan multicore terhadap kegagalan dapat diwujudkan
  • Cocok untuk aplikasi yang mengutamakan stabilitas dan performa dalam layanan produksi
  • Ini adalah proyek open source yang bernilai tinggi untuk dipelajari dan diterapkan dalam praktik, baik oleh startup, pengembang IT profesional, maupun pengembang umum

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-21
Opini Hacker News
  • Saya memulai proyek kecil dengan gleam/lustre, dan sejauh ini sangat puas
    Kalau Anda tertarik dengan static typing, lingkungan tanpa null, pemrograman fungsional, dan bahasa keluarga ML, saya sarankan mencoba gleam
    Dan tentu saja, ini juga berjalan di BEAM
    • Saya juga berpikir begitu
      Saat memasang gleam, sekitar 50 paket ikut terpasang di sistem saya, dan sepertinya itu paket terkait Erlang/Elixir
      Saya jadi penasaran bagaimana kalau hanya ingin transpile ke JS saja. Mungkin ini juga masalah packaging di sistem saya
      Akan lebih bagus kalau ada dukungan target transpile ke Lua. Menurut saya, untuk menanamkan DSL ke program lain, Lua terasa 3 kali lebih mudah daripada runtime JS
      Yang paling saya suka sejauh ini justru komunitasnya. Kualitas library dan materi di komunitas gleam sangat tinggi
      Ini mengingatkan saya pada komunitas Rust, di mana masalah-masalah sulit sudah ditangani orang-orang cerdas, jadi solusi yang bagus mudah ditemukan (lustre, squirrel, dll.)
      Ciri lainnya adalah banyak eksperimen dan percobaan kreatif. Hal-hal yang jarang terlihat di ekosistem bahasa yang besar justru menonjol di sini. Komunitasnya juga sangat ramah seiring pertumbuhannya
    • Saya tertarik dengan semua yang Anda sebutkan. Tapi saya masih belum benar-benar memahami BEAM atau OTP
      Ada rekomendasi sebaiknya mulai belajar dari mana?
    • Dari sudut pandang orang yang belum punya pengalaman dengan hal-hal yang disebut sebelumnya, saya penasaran mana yang lebih baik dipelajari dulu: gleam/lustre atau elixir/phoenix
  • Saya penasaran apakah orang yang memakai Gleam juga menggunakan framework web seperti Phoenix
    Saya sedang mencari tahu karena akan sangat bagus kalau framework seperti Phoenix bisa dipakai bersama Gleam
    Saat ini saya sedang menyiapkan proyek baru dengan Python, tapi kalau ada opsi yang layak dengan Gleam, saya ingin mencobanya
    • Ada video presentasi dari pengembang Lustre yang mengimplementasikan fitur mirip LiveView dengan Gleam/Lustre
      Keunggulannya adalah sangat mudah memilih bagian mana yang masuk frontend/backend
      Tautan YouTube
    • Belum ada framework lengkap seperti Phoenix, Django, atau Rails
      Tapi ada alat-alat yang sering dipakai saat membuat web app
      Lustre adalah tool view dasar, dan Wisp berperan sebagai server
      Untuk SQL ada squirrel dan POG (masih baru, tapi populer)
  • PureScript adalah bahasa pemrograman fungsional matang yang mendukung backend Erlang
    Jika Anda butuh alternatif static typing lain di BEAM, ini pilihan yang bagus
    Ini seperti dialek Haskell, dengan evaluasi ketat dan dukungan row polymorphism
    • Backend JS PureScript sudah matang, tetapi backend Erlang dan ekosistemnya jauh lebih kecil dibanding Gleam
    • Di situs resmi dan repo github resminya, yang tertulis hanya bahwa PureScript dikompilasi ke JS, jadi saya penasaran dari mana Anda mendengar soal backend Erlang
  • Saya sangat tertarik dengan Erlang/BEAM, tetapi belum sempat benar-benar mencobanya
    Saya penasaran bagaimana ini dipakai di dunia kerja. Apakah semua logika layanan dibangun di atasnya, atau hanya dipakai untuk bagian tertentu saja?
    • Saya memimpin tim yang sedang melakukan migrasi bertahap ke Gleam
      Kami menerapkan pola "functional core, imperative shell" sampai ekstrem, sehingga Gleam dipisahkan untuk menangani komputasi berat dari codebase Ruby on Rails yang sudah ada
      Kami hampir tidak memakai fitur OTP, dan Rails tetap difokuskan hanya pada kekuatan alaminya seperti web UI/HTTP API
      Rails menangani penyiapan nilai input untuk job, lalu data job dikirim ke Gleam sebagai satu set nilai atomik melalui Redis
      Kami membuat wrapper tipis dengan Elixir untuk menangani jaringan dan file IO, sementara logika bisnis ditangani modul Gleam
      Saya berencana menulis artikel dengan penjelasan teknis yang lebih rinci tentang pendekatan ini dalam waktu dekat. Ini topik yang sering menarik perhatian di HN
    • Di TV Labs, kami memakai Elixir untuk berbagai hal seperti layanan web, mesin matching real-time, sandboxing kode Lua, komunikasi dengan mikrokontroler melalui protokol biner, machine learning, dan lain-lain
      Elixir adalah bahasa yang sangat bagus untuk penggunaan umum, dan punya keunggulan di banyak bidang
      Untuk pembahasan lebih lanjut, lihat video Developer Voices saya
      Tautan YouTube
    • Saya sarankan datang ke elixirforum.com dan ikut berdiskusi
      Banyak orang benar-benar membangun sistem serius hanya dengan Erlang/Elixir & BEAM, jadi kalau Anda punya pertanyaan, biasanya akan dijawab dengan baik
    • Saya sudah melihat kedua pendekatan itu
      Begitu Anda cukup memahami OTP, membangun seluruh sistem di atasnya terasa alami
      Saya sendiri sudah melakukannya selama 7 tahun, tetapi saya juga melihat bahwa developer baru butuh waktu lama untuk terbiasa dengan ekosistem ini
  • Menurut saya, kalau Gleam ingin dianggap lebih serius, sebaiknya jangan menaruh pesan politik yang kuat di halaman proyeknya
    Saya tidak melihat perlunya memasukkan pembicaraan politik ke halaman proyek teknis
    Ini bukan soal setuju atau tidak setuju, tetapi menurut saya diskusi seperti itu lebih baik dikeluarkan dari ruang profesional
    Kalau tidak, percakapan jadi melenceng dari pokok bahasan tanpa perlu
    • "Black lives matter. Trans rights are human rights. No nazi bullsh*t."
      Maksud Anda kalimat satu baris yang muncul sekali di bagian bawah halaman itu?
      Kalau Anda memutuskan tidak memakainya hanya karena satu kalimat itu, saya rasa itu justru bekerja persis seperti yang dimaksudkan
    • Anda bilang "percakapan jadi melenceng dari pokok bahasan tanpa perlu"
      Menurut saya justru Andalah yang membuatnya melenceng dari pokok bahasan
  • Menurut saya, model actor menimbulkan masalah komputasi terdistribusi saat informasi harus dibagikan antarproses
    Dari sudut pandang saya, untuk toleransi kesalahan dan multicore, lebih baik memakai software transactional memory dan functional effect system seperti Scala/ZIO
    Meski begitu, model actor masih bisa dipakai saat memang dibutuhkan
    Selain itu, kalau melihat kematangan ekosistem JVM, observability, dan kesiapan produksi, itu lebih unggul daripada BEAM
    • Menurut saya ini sudut pandang yang cukup unik
      Saya paham kalau Anda ingin mengkritik kelemahan BEAM, tetapi rasanya aneh mengkritik justru bagian yang menjadi kekuatannya
      BEAM dibangun di atas pengiriman pesan immutable di antara green thread yang ringan dan murah
      Ada sistem pengawasan yang kokoh (supervisor trees), jadi tidak perlu khawatir soal data race atau thread yang berhenti
      Semua ini sudah bawaan, jadi tidak ada boilerplate
      Berkat immutability, performanya juga ternyata cukup baik
      Pada akhirnya, BEAM adalah platform yang paling dioptimalkan untuk sistem toleran gangguan serta sistem terdistribusi/konkuren
    • Ada satu hal yang belum disebut, yaitu Erlang (fondasi gleam) adalah bahasa yang telah mewujudkan uptime 99.9999999%
      Salah satu faktor besar yang memberi daya tahan seperti ini adalah supervising yang kuat serta infrastruktur lintas mesin
      Ini adalah bahasa yang sangat menginspirasi lahirnya sistem actor
      Secara harfiah, Erlang ada untuk satu hal ini, dan melakukannya dengan sangat baik
    • Anda bilang "model actor sulit untuk berbagi antarproses", padahal sebenarnya model actor bekerja dengan menyalin data atau memindahkan kepemilikan lewat pengiriman pesan
      Kalau memang ada data yang perlu benar-benar dibagi, maka data itu harus berupa data immutable
    • Saya penasaran apakah Anda bisa memberi contoh situasi ketika data mutable benar-benar tidak bisa diteruskan sebagai struktur data immutable
      Yang terpikir oleh saya hanya komputasi numerik yang sangat berat, tetapi untuk kasus seperti itu orang biasanya tidak menulisnya langsung di elixir atau erlang, melainkan mengimplementasikannya sebagai NIF
    • Di Elixir/Gleam/OTP, program pada dasarnya adalah kumpulan proses independen
      Bahkan tanpa memakai pola actor secara eksplisit, perpindahan state dan koordinasi sudah merupakan masalah yang terselesaikan
      Ada primitive bawaan seperti task, agent, GenServer, Supervisor, dan lainnya