2 poin oleh GN⁺ 2025-12-14 | 1 komentar | Bagikan ke WhatsApp
  • Menyelesaikan puzzle selama 12 hari di Advent of Code 2025 dengan Gleam, dan yang paling mengesankan adalah pesan error setingkat Rust serta gaya fungsional berpusat pada pipeline
  • Fungsi bawaan seperti echo, fold_until, dan list.transpose mempermudah debugging dan penyelesaian masalah kombinatorial, sementara keamanan berbasis tipe option bekerja efektif untuk menangani puzzle grid
  • Ketiadaan file IO dan fitur regex di pustaka standar, batasan pattern matching list, serta sintaks perbandingan yang eksplisit disebut sebagai hal yang terasa merepotkan saat sering digunakan
  • Karena adanya perbedaan penanganan integer antara target Erlang VM dan JavaScript, penggunaan bigi menjadi perlu, dan pada beberapa puzzle masalah diselesaikan dengan memanggil alat eksternal (glpsol)
  • Secara keseluruhan, peralihan ke pola pikir fungsional membuat penyelesaian puzzle menjadi lebih jelas, dan penulis menyatakan harapan untuk mencoba menerapkan Gleam pada proyek nyata seperti pengembangan web server

Advent of Code 2025 dan pilihan menggunakan Gleam

  • Penulis, yang setiap tahun selalu menuntaskan Advent of Code, tahun ini memilih bahasa Gleam untuk menyelesaikan puzzle selama 12 hari
    • Acara tahun ini dipangkas menjadi 12 hari alih-alih 25 hari, dan meskipun tingkat kesulitan tiap soal tinggi, strukturnya cocok untuk belajar
  • Laju puzzle yang cepat dan munculnya masalah kompleks sebelum toolset selesai dibangun menjadikannya lingkungan yang ideal untuk mempelajari bahasa baru

Kelebihan bahasa Gleam

  • Ditandai dengan sintaks yang ringkas, pesan error compiler yang berguna, dan umpan balik ramah setingkat Rust
  • Gaya fungsional yang berpusat pada operator pipe sangat cocok dengan struktur soal AoC (parsing → transformasi → fold)
  • Ekstensi Gleam untuk IntelliJ dan LSP bekerja stabil sehingga lingkungan pengembangan terasa nyaman
  • Functional programming (FP) mendorong perubahan cara berpikir dari kode imperatif menjadi cara mendeskripsikan esensi masalah

Fitur utama dan contoh penggunaan kode

  • echo: fungsi output sederhana untuk memeriksa nilai di tengah pipeline, sehingga debugging bisa dilakukan tanpa format string
    • Tidak adanya fitur interpolasi string disebut sebagai ketidaknyamanan karena pembuatan teks jadi sering memakai operator <>
  • Tipe option (dict.get): memungkinkan penelusuran tetangga pada puzzle grid secara aman tanpa pemeriksaan batas manual
  • Utilitas list
    • list.transpose: menyederhanakan struktur puzzle lewat operasi transpose matriks
    • list.combination_pairs: membuat pasangan titik 3D dalam satu baris tanpa nested loop
    • fold_until: fungsi fold yang bisa berhenti lebih awal saat kondisi terpenuhi, efisien untuk perhitungan berulang dalam puzzle

Batasan dan hal yang kurang nyaman di Gleam

  • Tidak ada file IO di pustaka standar, sehingga diganti dengan paket simplifile
  • Fitur regex juga memerlukan dependensi eksternal (gleam_regexp)
  • Batasan pattern matching list: bentuk [first, ..middle, last] tidak didukung
  • Penanganan eksplisit untuk operasi perbandingan: harus memakai tipe order, sehingga sintaks menjadi lebih panjang untuk perbandingan sederhana

Penggunaan lanjutan dan contoh per puzzle

  • bigi: digunakan untuk mencegah integer overflow saat menargetkan JavaScript
  • XOR bitmask: pada Day 10-1, masalah toggle lampu dimodelkan dengan operasi XOR agar terselesaikan secara efisien
  • Pemanggilan glpsol: pada Day 10-2, file LP dibuat lalu perintah eksternal dijalankan untuk menyelesaikan persamaan linear
  • Kunci memoization: pada Day 11-2, node dan state dipakai bersama sebagai key sehingga perhitungan langsung selesai
  • Puzzle terakhir bergantung pada asumsi input, dan diselesaikan dengan perbandingan area sederhana (heuristic_area <= max_area)

Kesimpulan dan rencana ke depan

  • Gleam menunjukkan kekuatan dalam keamanan dan daya ekspresi meski memiliki keterbatasan pustaka standar
  • Pipeline, tipe option/result, fungsi list, dan fold_until membuat penyelesaian puzzle lebih jelas
  • Ke depan, penulis berencana menerapkannya pada proyek nyata seperti pengembangan web server, dan menyatakan niat untuk terus memakai Gleam pada Advent of Code tahun berikutnya
  • Seluruh source code dipublikasikan di repositori GitHub (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

1 komentar

 
GN⁺ 2025-12-14
Komentar Hacker News
  • Gleam benar-benar bahasa yang indah. Rasanya menyenangkan jika Elixir berkembang ke arah seperti ini dalam hal sistem tipe
    Gleam juga berjalan di atas BEAM, yaitu VM Erlang, sehingga konkurensi dan pemrosesan antrean menjadi sangat mudah
    Ekosistemnya juga luar biasa. Hanya saja, sejak era LLM, saya khawatir perkembangan bahasa-bahasa baru setelah 2021 terasa seperti berhenti
    Meski begitu, Gleam masuk tepat sebelum pintu itu tertutup, dan saya berharap LLM akan segera bisa mengejarnya

    • Saya penasaran kenapa Anda berpikir LLM membuat perkembangan bahasa berhenti. Model terbaru sudah mencakup pengetahuan hingga tahun ini, dan bahasa baru pun bisa dipelajari cukup baik hanya dari beberapa contoh
      Karena bahasa-bahasa tidak mungkin sepenuhnya berbeda dari sisi sintaks maupun filosofi, rasanya itu bukan masalah besar
    • Tidak sepenuhnya tepat mengatakan bahwa Gleam dibangun di atas OTP. VM Erlang adalah BEAM, sedangkan OTP adalah kumpulan library dan prinsip desain untuk Erlang
      Gleam sendiri menyediakan subset OTP yang type-safe. Untuk library terkait, lihat gleam-lang/otp
    • Betul, VM Erlang adalah BEAM, bukan OTP. Implementasi OTP di Gleam belum sematang Elixir atau Erlang
    • Saya juga baru-baru ini membuat proyek pertama dengan Elixir yang mencakup fitur LLM, dan justru merasa tren seperti ini bisa mendorong adopsi bahasa
    • Elixir juga sedang secara bertahap mengadopsi set-theoretic typing. Dokumen terkait: gradual-set-theoretic-types
  • Saya mencoba menyelesaikan Advent of Code tahun ini dengan Gleam, dan cukup terkesan
    Kelebihannya adalah performanya bagus, dan language server-nya sangat kuat. Auto-formatting, auto import, pelengkapan pattern matching, semuanya membuat pengalaman pengembangan sangat baik
    Kekurangannya, formatter terlalu sering membuat kode memanjang ke bawah, dan karena terlalu menekankan kesederhanaan, ada banyak pengulangan penulisan seperti list.map. Selain itu, ekosistem library-nya masih kurang

    • Saya juga terkejut dengan performanya. Memang tidak secepat C, tapi jauh lebih cepat dari yang saya duga. Language server-nya juga berjalan baik di hampir semua IDE
      list.map bisa dipersingkat seperti import gleam/list.{range, map}. Mem-porting library C juga sepertinya menarik
    • Kekurangan itu masih bisa ditoleransi, tetapi tidak adanya if/else atau guard terasa merepotkan. Penanganan percabangan boolean jadi terlalu bertele-tele
    • Saya mengerjakan AoC dengan F#, dan rasanya mirip. Pengulangan namespace seperti List.map menurunkan discoverability
    • Pemformatan argumen itu mungkin karena algoritma Prettier. Meski begitu, menurut saya tetap jauh lebih baik daripada binpacking di clang-format
  • Saya suka Gleam, tetapi saya merasa sayang dengan batasan pemanggilan fungsi rekursif. Pemanggilan fungsi internal tidak sebebas itu
    Secara sintaks, ia kurang elegan dibanding Scheme, dan secara konsep lebih sederhana daripada Erlang. Namun static typing tetap menjadi kelebihan
    Saya juga pernah memakai OCaml, tetapi reproduktibilitas lingkungannya kurang baik karena masalah lock file di opam, dan saya berharap ekosistem SML lebih besar

    • Saya juga punya kesan serupa. Haskell secara teori memang keren, tetapi bahkan hello world sederhana pun menghabiskan resource besar
      Idris 2 punya dependent types dan desain yang elegan, tetapi ekosistemnya kecil, sementara PureScript lebih praktis daripada Haskell namun terikat pada runtime JS
    • Jika Anda menyukai keluarga ML, saya merekomendasikan ReScript v12. Posisinya cukup seimbang di antara OCaml dan Gleam
  • Saat melihat fitur echo, saya merasa akan bagus jika debugger punya fitur melihat hasil antara seperti ini secara bawaan
    Akan menyenangkan jika hasil antara dari array slice atau rantai filter bisa dilihat tanpa harus mengubah kode
    Saya juga menganggap memakai array 2D sebagai grid itu tidak efisien. Array 1D + informasi batas lebih aman dan efisien

  • Saya tidak terlalu tahu Gleam, tetapi list.map(fn(line) { line |> calculate_instruction })
    bukankah bisa langsung ditulis sebagai list.map(calculate_instruction)?

    • Betul, saya juga kadang sempat melakukan pemrosesan yang lebih rumit lalu menghapusnya dan meninggalkan bentuk itu
    • Ya, itu benar
  • Gleam adalah bahasa yang luar biasa. Bagi saya pribadi tidak terlalu cocok, tetapi senang melihat orang-orang menikmatinya
    Saya merasa kombinasi Gleam + Lustre bisa menjadi Elm yang baru

    • Sebagai pengembang backend, Elm dulu terasa menarik, tetapi saya menjauh karena konflik dengan pembuatnya dan berhentinya rilis. Meski begitu, arsitekturnya tetap berguna di proyek lain
    • Saya juga baru-baru ini membuat aplikasi kecil dengan Gleam + Lustre, dan hasilnya jauh lebih baik daripada Elm + PostgREST. Sekarang saya berencana memakainya untuk proyek yang lebih besar
    • Saya sempat melihat Lustre, tetapi ekosistemnya masih kecil. Bahkan tidak ada contoh terkait autentikasi, jadi saya memilih LiveView. Meski begitu, ergonomics-nya bagus dan saya berharap ia berkembang
  • Belakangan ini saya memikirkan apakah masih ada gunanya mempelajari bahasa baru di era LLM
    Jika itu bahasa yang belum dipelajari LLM, saya khawatir kegunaan praktisnya sebagai alat akan berkurang

    • Dalam jangka panjang, jika LLM tidak bisa mempelajari bahasa baru, berarti ia gagal mencapai tujuannya sebagai kecerdasan umum
    • Kekhawatiran seperti itu memang ada 1–2 tahun lalu, tetapi sekarang Claude Code sudah cukup bagus menulis kode Elixir. Data pelatihan yang sedikit pun bukan masalah besar
    • Claude juga cukup baik menangani Gleam. Dokumentasinya dan kualitas pesan diagnostik-nya bagus, jadi mudah dipelajari LLM. Ia memberi diagnostik setingkat Rust
      Sebaliknya, Swift sulit ditangani LLM karena sintaksnya rumit
    • Jika bahasa dipandang sebagai alat, kurangnya permintaan pasar mungkin justru menjadi batasan yang lebih besar
    • Saya berharap bahasa-bahasa baru tidak berhenti karena keterbatasan LLM
  • Saat dulu melihat Gleam, sepertinya ia tidak punya dynamic dispatch (interface atau type class), dan saya penasaran apakah sekarang masih begitu

    • Biasanya itu diatasi dengan pendekatan “kirim struct berisi fungsi”. Karena pendekatannya eksplisit, justru enak karena bebas dari kompleksitas generics
    • Gleam mendukung fungsi kelas satu, jadi dynamic dispatch tetap memungkinkan. Type class atau interface pada akhirnya juga bisa diwujudkan dengan higher-order function
  • [first, ..rest] atau [first, second] bisa, tetapi [first, ..middle, last] tidak bisa.
    Mungkin memang sengaja dibatasi karena biayanya mahal

  • Untungnya polisi judul blog segera datang
    Tautan terkait