Lisette — Rust sözdizimine dayanıp Go çalışma zamanına derlenen küçük bir dil

• Rust tarzı sözdizimi kullanırken Go çalışma zamanı üzerinde çalışan küçük bir dil; iki dilin avantajlarını bir araya getiriyor
• Cebirsel veri tipleri, örüntü eşleme, Hindley-Milner tip sistemi, varsayılan değişmezlik gibi özelliklerle güvenlik ve ifade gücü artırılmış bir yapı sunuyor
• Go paketlerini doğrudan import etme, pipeline operatörü, try blokları, task tabanlı eşzamanlılık ile Go ekosistemiyle birlikte çalışabilirlik sağlıyor
• Derleme zamanında hata tespiti, açık tanı mesajları, LSP desteği ile geliştirici deneyimi ve kod güvenilirliği iyileşiyor
• En önemli nokta, Lisette kodunun okunması kolay Go koduna dönüştürülmesi ve böylece mevcut Go projeleriyle doğal biçimde entegre edilebilmesi

---

Lisette genel bakış

• Lisette, Rust sözdizimini temel alan ve Go çalışma zamanına derlenen küçük bir dil
• Cebirsel veri tipleri, örüntü eşleme, nil olmaması, Hindley-Milner tip sistemi, varsayılan değişmezlik, Go ekosistemiyle birlikte çalışabilirlik gibi özelliklere sahip
• cargo install lisette komutuyla kurulabiliyor; ayrıca Go'nun fmt, io, os gibi paketleri doğrudan import edilerek kullanılabiliyor

Tanıdık sözdizimi

• Rust'a benzer bir sözdizimsel yapı sunuyor
  • enum ve match ile örüntü eşleme desteği sağlıyor
  • struct ve impl bloklarıyla metot tanımı yapılabiliyor
• İfade odaklı bir dil olarak if, let, bloklar gibi yapıların tümü değer döndürüyor
• Chaining ve lambda desteği sayesinde ortam değişkeni işleme veya string manipülasyonu kısa ve net biçimde ifade edilebiliyor
• Arayüzler ve generics destekleniyor; interface tanımı ve T: Trait kısıtlarıyla generic fonksiyonlar yazılabiliyor
• if let ve let else sözdizimiyle Option tipi kısa ve anlaşılır biçimde ele alınabiliyor

Güvenlik

• Go çalışma zamanında ortaya çıkabilecek hataları derleme zamanında tespit eder

  • match ifadesinde tüm örüntüler ele alınmazsa hata oluşur
  • nil kullanılamaz, eksik değerler Option<T> ile ifade edilir
  • Result dönüş değerleri yok sayılırsa uyarı verilir
  • Özel tiplerin açık API'de dışa vurulması durumunda uyarı oluşur
  • Değişmez değişkenin değiştirilebilir argüman olarak geçirilmesi hata üretir
  • Struct alanı eksikse derleme hatası oluşur
  • Tanı mesajları, somut kod konumu ve düzeltme önerileri ile birlikte sunulur
  • LSP(Language Server Protocol) desteği sayesinde VSCode, Neovim, Zed gibi başlıca editörlerde kullanılabilir

Kullanılabilirlik

• Tasarımın odağında Go ile birlikte çalışabilirlik bulunuyor
• Pipeline operatörü(|>) ile fonksiyon zincirleme daha kısa ifade ediliyor
• try blokları, hata yayılımını basitleştiriyor
• Eşzamanlılık, task ve Channel kullanılarak Go'nun goroutine yapısına benzer şekilde uygulanıyor
• Serileştirme attribute'ları ile JSON alan adı, atlama, string dönüşümü, doğrulama etiketleri gibi ayarlar yapılabiliyor
• panic kurtarması için recover bloğu sunuluyor ve Result tipiyle güvenli hata yönetimi sağlanabiliyor
• defer sözdizimi desteklenerek kaynak temizliği veya transaction rollback garanti altına alınabiliyor

Şeffaf derleme çıktısı

• Lisette kodu, açık ve okunması kolay Go koduna dönüştürülür
  • Option ve Result tipleri sırasıyla lisette.Option ve lisette.Result struct'larına dönüştürülür
  • match sözdizimi, Go'nun koşul ifadelerine çevrilerek her dal işlenir
  • ? operatörü, iç tarafta Result kontrol koduna dönüştürülür
• Örneğin classify fonksiyonu Option<int> alır ve Go'da açık koşul ifadelerine dönüştürülür; combine fonksiyonu ise Result kontrolü yapan Go koduna çevrilir

Ek bilgiler

• Resmi depo: github.com/ivov/lisette
• MIT lisansı ile yayımlanmış olup, 2026 itibarıyla Iván Ovejero tarafından geliştiriliyor

[GN⁺]

Hacker News görüşleri

• Yazarla konuşma fırsatım oldu ve dili bizzat denememiş olsam da Lisette ilgi çekici ve Go’ya kıyasla açıkça iyileştirilmiş bir dil gibi görünüyor
  Yine de Go’nun sınırlamalarını tamamen aşmanın zor olduğunu düşünüyorum. Örneğin, Go’nun arayüz tiplerinden kaynaklanan typed nil sorunu Lisette’te Option ile ele alınıyor, ancak çift açma (Some(Some(h))) garip hale gelebilir
  Ayrıca Go’nun defer yaklaşımı hâlâ rahatsız edici ve RAII gibi otomatik kaynak serbest bırakma sağlamıyor
  TypeScript’in JavaScript’i tamamlayabilmesinin nedeni, tarayıcıda çalışabilecek bir alternatifin olmamasıydı; artık WASM var, dolayısıyla durum farklı
  Bu yüzden “Rust varken neden Go’yu Rust gibi yapalım?” sorusu akla geliyor. Yine de Lisette sanki bu ikisinin arasındaki noktayı hedefliyor
  Sonuç olarak Lisette, mevcut Go kod tabanlarını iyileştirmek veya Go runtime’ını kullanmaya devam etmek isteyenler için uygun bir dil gibi görünüyor
  Benim merak ettiğim şey, “Şu dosyayı Go yerine Lisette ile yazmaya başlamak istesem nasıl başlarım?” sorusuna yanıt veren bir hızlı başlangıç rehberinin olmaması
  İlgili blog yazısı: Go is still not good

  • Go, GC tabanlı eşzamanlılık runtime’ı sunması bakımından hâlâ benzersiz
    Karmaşık referans grafiklerini ele alan problem alanlarında GC zorunlu ve Go’nun kullanıcı modu stack yapısı sayesinde verimli bir bellek modeline sahip
  • GC dillerinde geliştirme hızı çok daha yüksek oluyor. Rust ve Python ile chatbot yaptım; Rust deneyimim olmasına rağmen Python çok daha hızlıydı
    Go, böyle hızlı CLI araçları geliştirmek için de uygun — örn: wordle-tui
  • Go, dil olarak birçok tuhaflığa sahip ama derleme hedefi olarak mükemmel
    Söz dizimi basit, çapraz platform desteği var, runtime ve GC gömülü geliyor, “errors as values” yapısı, green thread’ler, hızlı AOT derleyicisi gibi pek çok avantaj sunuyor
    Go’nun defer özelliği kullanışlı olsa da hata işleme ve scope kuralları garip
  • Blogda geçen “Go, NULL’ı yanlışlıkla iki kez icat etmiş bir dil” ifadesi akılda kalıcıydı
    TypeScript de bu sorunu çözemedi, hatta daha da kötü. Bu yüzden kendim bir Option type paketi yapıp NPM’e koydum → fp-sdk
  • Rust’ın async yapısı, GC olmadığı için Go kadar rahat değil. Sırf bu bile Go runtime’ını seçmek için bir neden

• Go’ya derlenen diller zaten birkaç tane var — XGo, Borgo, Soppo vb.

  • Borgo ve Lisette, (T, error) dönüşünü basitçe Result tipi ile değiştiriyor, ancak bu anlamsal olarak tamamen aynı değil
    Örneğin io.Reader.Read için (n!=0, io.EOF) normal sonlanma anlamına gelir; bunu basitçe hata diye ele almak yanlış davranışa yol açar
  • Derleme hatalarının hedef dilden kaynak dile nasıl aktarıldığını merak ediyorum

• Lisette’in hata mesajı kalitesi etkileyici. “help” ipuçları gerçekten faydalı hissettiriyor
  Ancak Go’ya dönüştürülen kodun çok ayrıntılı ve uzun olabilmesi nedeniyle, runtime hatası olduğunda Go kodunda debug yapmak gerekmesi endişe verici
  Ayrıca mevcut Go kodundan Lisette’i çağırma yönü zor görünüyor
  Lisette’in deneysel bir dil mi olduğu, yoksa gerçekten production’ı mı hedeflediği merak konusu

  • Geliştirici doğrudan yanıt verdi: lis run --debug seçeneği kullanıldığında Go koduna //line source.lis:21:5 yorumları ekleniyor ve stack trace özgün Lisette koduna eşleniyor
    LSP, derleme zamanı hatalarını .lis dosyaları üzerinden işliyor
    Şu anda Go’dan Lisette çağırma özelliği yok, ancak öncelik Lisette içinden Go paketlerini import etme desteğinde
    Başlangıçta bir deneydi ama hedef bunu production seviyesinde bir dil haline getirmek

• Rust’a benzer söz dizimi neden doğrudan alınmamış, bunu merak ediyorum
  Örn: import "foo.bar" yerine use foo::bar, Bar.Baz => yerine Bar::Baz => gibi
  Rust bilenler için kafa karıştırıcı oluyor, bilmeyenler içinse Rust bilgisine aktarım sağlamıyor

  • Bu söz dizimi farkları küçük ayrıntılar; asıl önemli nokta Rust’ın tip sistemini Go’ya getirmek
    int ve float64, Go’nun tip adlandırma kurallarını takip ediyor
  • Birden çok dil arasında gidip gelince söz dizimi benzerliği bazen tersine karışıklık yaratıyor. Örneğin PHP’de + yerine . kullanmak gerektiğini sık sık unutuyorum
  • Ben de önce TypeScript tabanlı, Rust tarzı bir dil yapmayı düşünmüştüm ama sonunda Rust’ın kendisinin sanıldığı kadar zor olmadığını fark ettim
  • GC dilinde Rust tarzı bir bellek modelini uygulamak oldukça doğal olmayan bir şey. Her nesnenin bağımsız bir adres alanına sahip olması gibi bir durum ortaya çıkıyor ve bu da karmaşık
  • Lisette, Rust’tan ilham alan bir dil; Rust’ın kendisi olmaya çalışmıyor. Ana hedef kitlesi Go geliştiricileri

• Go runtime’ı iyi ama dilin kendisi kaba ve gelişmeye pek niyeti yokmuş gibi duruyor
  Bu yüzden transpiler kullanacak kadar ileri gidiliyorsa, gerçekten Go’dan nefret ediliyor olmalı

• Rust ve Rust benzeri dillerin struct ile method’u ayırmasının nedeni ne, bunu merak ediyorum
  Neden method’ları doğrudan struct içinde tanımlayamıyoruz?

  • Rust’ta struct alanları auto-trait’leri etkilediği için alanları bir bakışta görebilmek önemli
    Ayrıca impl blokları, struct’tan farklı generic kısıtlar taşıyabildiğinden birden fazla tane tanımlanabiliyor
    Son olarak Rust, verinin şekli (Shape) etrafında düşünmeye yönelten bir dil olarak tasarlanmış
  • Kişisel olarak impl blokları bana Go’daki method’ları hatırlatıyor; hangisinin daha iyi olduğunu söylemek zor

• Python gibi görünen ama Rust’a veya Go’ya derlenen bir dil olsa gerçekten harika olurdu

  • Mojo, Swift’in yaratıcısı tarafından geliştirilen Python söz dizimli yüksek performanslı bir dil
  • Spy, C’ye derlenen erken bir girişim; Nim de benzer çizgide olgun bir dil
  • Nim, Python’a benzer söz dizimine sahip, statik tip sistemi sunan ve wasm ile C gibi çeşitli hedeflere derlenebilen bir dil
  • Static Python Skill, Python’ı statik olarak derlemeye yönelik bir girişim
  • Grumpy, Google’ın geliştirdiği bir Python→Go transpiler’ıydı, ancak 9 yıldır güncellenmiyor (Python 2.7 hedefli)

• Lisette, Go’nun sadeliği ile Rust’ın karmaşıklığı arasında iyi bir denge kuran bir dil gibi görünüyor
  Derleme hızının neden Go’dan çok daha yavaş olması gerektiğini ve Rust özelliklerinden hangilerinin bilinçli olarak dışarıda bırakıldığını merak ediyorum
  Örn: borrow checking, veri tipleri, async vb.

• Go öğrenmesi kolay ama özellikleri eksik bir dil
  Lisette bu boşluğu dolduran bir dil gibi göründüğü için ilgi çekici
  TypeScript’in JavaScript’i genişletmesi gibi, Go’ya ifade gücü yüksek bir tip sistemi ve katı bir derleyici eklenirse harika bir backend dili olabilir
  Benim kişisel önerim, TypeScript frontend ile tip paylaşımını desteklemesi olurdu. TypeScript’in backend’de de popüler olmasının nedenlerinden biri bu

• Rust’ın güvenliği ile Go’nun sadeliği arasında kararsız kalan bir altyapı otomasyonu geliştiricisi olarak, Rust’ın kullanılabilirliğini Go runtime’ı üzerine koyma fikri bana çok çekici geliyor
  Projenin gelişimini izlemeye devam edeceğim