Advent of Code için Gleam kullanma deneyimi

• Advent of Code 2025'in 12 günlük bulmacaları Gleam ile çözüldü; dilin özellikle Rust düzeyinde hata mesajları ve pipeline merkezli işlevsel tarzı etkileyici bulundu
• echo, fold_until, list.transpose gibi yerleşik fonksiyonlar hata ayıklamayı ve kombinasyon problemlerini çözmeyi basitleştirirken, opsiyon tipi tabanlı güvenlik grid bulmacalarını işlerken faydalı oldu
• Standart kütüphanede dosya G/Ç ve regex özelliklerinin yer almaması, liste pattern matching kısıtları, açık karşılaştırma sözdizimi gibi noktalar tekrar eden kullanımda rahatsız edici unsurlar olarak belirtildi
• Erlang VM ile JavaScript hedefi arasındaki tamsayı işleme farkı nedeniyle bigi kullanımı gerekti; bazı bulmacalarda ise sorun harici araç (glpsol) çağrısıyla çözüldü
• Genel olarak işlevsel düşünceye geçiş bulmaca çözümünü daha net hale getirdi ve Gleam'i gerçek projelerde (ör. web sunucusu geliştirme) deneme isteği ifade edildi

---

Advent of Code 2025 ve Gleam seçimi

• Her yıl Advent of Code'u tamamlayan yazar, bu yıl 12 günlük bulmacaları çözmek için Gleam dilini seçti
  • Bu yıl etkinlik 25 gün yerine 12 güne indirildi; her sorunun zorluk seviyesi yüksekti ama öğrenme için uygun bir yapı sundu
• Bulmacaların temposu hızlıydı ve araç seti tamamlanmadan karmaşık problemlere gelindi; bu da yeni bir dil öğrenmek için ideal bir ortam yarattı

Gleam'in dilsel avantajları

• Kısa ve sade söz dizimi, yararlı derleyici hata mesajları, Rust düzeyinde kullanıcı dostu geri bildirim öne çıkıyor
• Pipe operatörü merkezli işlevsel tarz, AoC problem yapısına (ayrıştırma → dönüştürme → fold) çok iyi uyuyor
• IntelliJ için Gleam eklentisi ve LSP kararlı çalıştığı için geliştirme ortamı rahattı
• İşlevsel programlama (FP), imperatif koda kıyasla düşünceyi problemin özünü tarif etme biçimine kaydırıyor

Öne çıkan özellikler ve kod kullanım örnekleri

• echo: Pipeline'ın ortasında değeri görmeye yarayan basit bir çıktı fonksiyonu; string formatlama olmadan hata ayıklama yapılabiliyor
  • String interpolation olmadığı için metin üretirken <>" işleminin sıklaşması rahatsız edici bir nokta olarak anıldı
• Opsiyon tipi (dict.get): Grid bulmacalarında sınır kontrolü yazmadan güvenli komşu araması yapılabiliyor
• Liste yardımcıları
  • list.transpose: Matris transpozisyonuyla bulmaca yapısını sadeleştiriyor
  • list.combination_pairs: 3D nokta çiftlerini iç içe döngüler olmadan tek satırda üretmeyi sağlıyor
  • fold_until: Koşul sağlandığında erken durabilen bir fold fonksiyonu olarak, bulmacalardaki yinelemeli hesaplamalarda verimli

Gleam'in kısıtları ve rahatsız edici yönleri

• Standart kütüphanede dosya G/Ç yok, bunun yerine simplifile paketi kullanıldı
• Regex işlevleri için de harici bağımlılık (gleam_regexp) gerekiyor
• Liste pattern matching kısıtları: [first, ..middle, last] biçimi desteklenmiyor
• Karşılaştırma işlemlerinin açıkça ele alınması: order tipi kullanılmalı; bu da basit karşılaştırmalarda söz dizimini uzatıyor

İleri kullanım ve bulmaca bazlı örnekler

• bigi: JavaScript hedefinde tamsayı taşmasını önlemek için kullanıldı
• XOR bitmask: 10. Gün 1. bölümde ışık açma-kapama problemi XOR işlemiyle modellenerek verimli biçimde çözüldü
• glpsol çağrısı: 10. Gün 2. bölümde lineer denklemleri çözmek için LP dosyası üretildikten sonra harici komut çalıştırıldı
• Memoization anahtarı: 11. Gün 2. bölümde düğüm ve durum birlikte anahtar olarak kullanıldı ve hesaplama hemen tamamlandı
• Son bulmaca girdi varsayımına bağımlıydı ve basit alan karşılaştırması (heuristic_area <= max_area) ile çözüldü

Sonuç ve gelecek planları

• Gleam, standart kütüphane sınırlamalarına rağmen güvenlik ve ifade gücü açısından güçlü yanlar gösterdi
• Pipeline, opsiyon/sonuç tipleri, liste fonksiyonları, fold_until gibi özellikler bulmaca çözümünü daha anlaşılır hale getirdi
• Gelecekte web sunucusu geliştirme gibi gerçek projelerde kullanım planlanıyor; gelecek yıl Advent of Code'da da Gleam'i sürdürme niyeti dile getiriliyor
• Tüm kaynak kod GitHub deposunda açık olarak paylaşıldı (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

[GN⁺]

Hacker News yorumları

• Gleam gerçekten güzel bir dil. Keşke Elixir tip sistemi açısından bu yönde evrilseydi diye düşünüyorum
  Gleam de Erlang VM’i olan BEAM üzerinde çalışıyor; bu sayede eşzamanlılık ve kuyruk işleme çok kolay
  Ekosistemi de harika. Ama LLM çağından sonra 2021 sonrasında dil gelişiminin durmuş gibi görünmesi endişe verici
  Yine de Gleam o kapı kapanmadan hemen önce iyi bir giriş yaptı; yakında LLM’lerin de onu yakalayacağını umuyorum

  • LLM’lerin dil gelişimini neden durduracağını düşündüğünü merak ediyorum. En yeni modeller bu yıla kadar olan bilgiyi içeriyor ve yeni dilleri de birkaç örnekle oldukça iyi öğreniyor
    Diller sözdizimi ya da felsefe olarak tamamen farklı olamayacağı için bunun büyük bir sorun olacağını sanmıyorum
  • Gleam’in OTP üzerine kurulduğunu söylemek tam olarak doğru değil. Erlang VM BEAM’dir ve OTP, Erlang’ın kütüphaneleri ile tasarım ilkeleri bütünüdür
    Gleam kendi içinde tip güvenli bir OTP alt kümesi sunuyor. İlgili kütüphane için bkz. gleam-lang/otp
  • Evet, Erlang VM BEAM’dir, OTP değil. Gleam’in OTP uygulaması Elixir ya da Erlang kadar olgun değil
  • Ben de yakın zamanda Elixir ile ilk kez LLM özellikleri içeren bir proje yaptım; hatta bu akımın dil benimsenmesini hızlandırabileceğini düşündüm
  • Elixir de kademeli olarak set-theoretic typing benimsiyor. İlgili belge: gradual-set-theoretic-types

• Bu yıl Advent of Code’u Gleam ile çözdüm ve oldukça etkilendim
  Artıları arasında performansın iyi olması ve dil sunucusunun şaşırtıcı derecede güçlü olması var. Otomatik biçimlendirme, otomatik import, pattern matching tamamlama gibi yönleriyle geliştirme deneyimi çok iyi
  Eksileri ise formatter’ın kodu gereğinden fazla dikey uzatması ve sadeliğe verilen önem nedeniyle list.map gibi tekrarların çok olması. Bir de kütüphane ekosistemi hâlâ yetersiz

  • Ben de performansa şaşırdım. C kadar değil ama beklediğimden çok daha hızlı. Dil sunucusu da neredeyse tüm IDE’lerde iyi çalışıyor
    list.map, import gleam/list.{range, map} şeklinde kısaltılabilir. C kütüphanelerini port etmek de ilginç olabilir
  • Eksileri katlanılabilir ama if/else ya da guard olmaması rahatsız edici. Boolean dallanmaları fazla ayrıntılı hale geliyor
  • AoC’yi F# ile yaptım, benzer bir his verdi. List.map gibi namespace tekrarları keşfedilebilirliği (discoverability) azaltıyor
  • Argüman biçimlendirmesi muhtemelen Prettier algoritması yüzündendir. Yine de bence clang-format’ın binpacking yaklaşımından çok daha iyi

• Gleam’i seviyorum ama özyinelemeli fonksiyon çağrısı kısıtları hayal kırıklığı yaratıyor. İç fonksiyon çağrıları serbest değil
  Sözdizimi olarak Scheme’den daha az zarif, kavramsal olarak ise Erlang’dan daha basit. Yine de statik tipleme önemli bir artı
  OCaml de kullandım ama opam’in lock dosyası sorunları yüzünden ortamı yeniden üretmek zordu. Keşke SML ekosistemi daha büyük olsaydı

  • Ben de benzer düşünüyorum. Haskell teoride çok hoş ama basit bir hello world bile kaynak tüketimi açısından ağır
    Idris 2, bağımlı tipler ve zarif bir tasarıma sahip ama ekosistemi küçük; PureScript ise Haskell’den daha pratik olsa da JS çalışma zamanına bağlı
  • ML ailesini seviyorsanız ReScript v12 öneririm. OCaml ile Gleam arasında dengeli bir yerde duruyor

• echo özelliğini görünce, hata ayıklayıcıda buna benzer bir ara sonuç görüntüleme özelliği keşke varsayılan olarak olsa diye düşündüm
  Dizi slice’ları veya filter zincirlerinin ara sonuçlarını kodu değiştirmeden görebilmek güzel olurdu
  Ayrıca iki boyutlu dizileri grid olarak kullanmanın verimsiz olduğunu düşünüyorum. Tek boyutlu dizi + sınır bilgisi daha güvenli ve daha verimli

• Gleam’i çok bilmiyorum ama list.map(fn(line) { line |> calculate_instruction })
  yerine doğrudan list.map(calculate_instruction) yazılamaz mı diye düşündüm

  • Evet, ben de bazen daha karmaşık bir işlem yaparken sonra onu silip o biçimi bırakmış oluyorum
  • Evet, doğru

• Gleam harika bir dil. Bende çok büyük bir karşılık bulmadı ama insanların ondan keyif aldığını görmek güzel
  Gleam + Lustre kombinasyonu yeni Elm olabilir diye düşünüyorum

  • Backend geliştiricisi olarak Elm bana çekici gelmişti ama yaratıcısıyla yaşanan anlaşmazlıklar ve sürümlerin durması yüzünden uzaklaştım. Yine de o mimari başka projelerde de faydalı oldu
  • Ben de yakın zamanda Gleam + Lustre ile küçük bir uygulama yaptım ve Elm + PostgREST’e göre çok daha iyi sonuç aldım. Şimdi bunu daha büyük projelerde de kullanmayı planlıyorum
  • Lustre’a baktım ama ekosistem hâlâ küçük. Kimlik doğrulama ile ilgili örnekler de yoktu, bu yüzden LiveView’a yöneldim. Yine de ergonomisi iyi, umarım büyür

• Bugünün LLM çağında yeni bir dil öğrenmenin değerli olup olmadığını düşünüyorum
  Eğer LLM’in eğitilmediği bir dilse, araç olarak faydası azalır mı diye endişeliyim

  • Uzun vadede LLM’ler yeni dilleri öğrenemezse, genel zekâ hedefinde başarısız olmuş olurlar
  • 1-2 yıl önce böyle kaygılar vardı ama artık Claude Code, Elixir kodunu da oldukça iyi yazıyor. Eğitim verisi az olsa bile sorun olmuyor
  • Claude, Gleam’i de iyi kullanıyor. Belgeler ve tanı mesajlarının kalitesi yüksek olduğu için LLM’lerin öğrenmesi kolay. Rust seviyesinde tanılar veriyor
    Buna karşılık Swift’in sözdizimi karmaşık olduğu için LLM’lerin işlemesi daha zor
  • Dili bir araç olarak görüyorsanız, piyasada talep eksikliği daha büyük bir kısıt olabilir
  • Umarım yeni diller LLM’lerin sınırlamaları yüzünden duraksamaz

• Daha önce Gleam’e baktığımda dinamik dispatch (interface ya da type class) yok gibi görünüyordu; şimdi durumun nasıl olduğunu merak ediyorum

  • Genelde “fonksiyon taşıyan bir struct geçir” yaklaşımıyla çözülüyor. Açık yaklaşım olduğu için jeneriklerin karmaşıklığından uzak kalması hoşuma gidiyor
  • Gleam birinci sınıf fonksiyonları desteklediği için dinamik dispatch mümkün. Type class ya da interface sonuçta yüksek dereceli fonksiyonlarla ifade edilebilir

• [first, ..rest] ya da [first, second] mümkün ama [first, ..middle, last] mümkün değil.
  Muhtemelen maliyeti yüksek olduğu için bilerek engellenmiş

• Neyse ki blog başlığı polisi hızlıca olaya müdahale etti
  İlgili bağlantı