Lisette — Bahasa kecil yang dikompilasi ke runtime Go dengan sintaks berbasis Rust

• Bahasa kecil yang berjalan di atas runtime Go sambil menggunakan sintaks bergaya Rust, menggabungkan keunggulan kedua bahasa
• Struktur yang memperkuat keamanan dan daya ekspresif melalui algebraic data type, pattern matching, sistem tipe Hindley-Milner, dan immutability secara default
• Menjamin interoperabilitas dengan ekosistem Go melalui import langsung paket Go, operator pipeline, blok try, dan konkurensi berbasis task
• Meningkatkan pengalaman pengembang dan stabilitas kode dengan deteksi kesalahan saat compile time, pesan diagnostik yang jelas, dan dukungan LSP
• Poin utamanya adalah kode Lisette diubah menjadi kode Go yang jelas dan mudah dibaca, sehingga bisa terintegrasi secara alami dengan proyek Go yang sudah ada

---

Gambaran umum Lisette

• Lisette adalah bahasa kecil berbasis sintaks Rust yang dikompilasi ke runtime Go
• Memiliki karakteristik seperti algebraic data type, pattern matching, tanpa nil, sistem tipe Hindley-Milner, immutability secara default, dan interoperabilitas dengan ekosistem Go
• Dapat diinstal dengan perintah cargo install lisette, dan bisa langsung mengimpor serta menggunakan paket Go seperti fmt, io, os

Sintaks yang familier

• Memiliki struktur sintaks yang mirip Rust
  • Mendukung pattern matching melalui enum dan match
  • Definisi method dimungkinkan dengan blok struct dan impl
• Sebagai bahasa yang berorientasi ekspresi, if, let, dan blok semuanya mengembalikan nilai
• Mendukung chaining dan lambda sehingga pemrosesan environment variable atau manipulasi string bisa ditulis dengan ringkas
• Mendukung interface dan generic, dan memungkinkan penulisan fungsi generik melalui definisi interface serta constraint T: Trait
• Tipe Option dapat ditangani secara ringkas dengan sintaks if let dan let else

Keamanan

• Mendeteksi kesalahan yang dapat terjadi di runtime Go saat compile time

  • Jika tidak semua pola ditangani dalam pernyataan match, akan muncul error
  • nil tidak bisa digunakan, nilai yang hilang direpresentasikan dengan Option<T>
  • Jika nilai kembalian Result diabaikan, akan muncul peringatan
  • Muncul peringatan jika tipe privat diekspos dalam API publik
  • Akan terjadi error jika variabel immutable diteruskan sebagai argumen yang bisa diubah
  • Jika field struct terlewat, akan terjadi compile error
  • Pesan diagnostik menyertakan lokasi kode yang spesifik dan saran perbaikan
  • Dapat digunakan di editor utama seperti VSCode, Neovim, dan Zed dengan dukungan LSP(Language Server Protocol)

Kegunaan

• Dirancang dengan fokus pada interoperabilitas dengan Go
• Operator pipeline(|>) memungkinkan chaining fungsi ditulis dengan ringkas
• Blok try menyederhanakan propagasi error
• Konkurensi diimplementasikan menggunakan task dan Channel, mirip dengan goroutine di Go
• Dengan atribut serialisasi, nama field JSON, penghilangan field, konversi string, dan tag validasi dapat ditentukan
• Menyediakan blok recover untuk pemulihan panic, dan penanganan error yang aman dengan tipe Result
• Mendukung sintaks defer untuk menjamin pembersihan resource atau rollback transaksi

Hasil kompilasi yang transparan

• Kode Lisette diubah menjadi kode Go yang jelas dan mudah dibaca
  • Tipe Option dan Result masing-masing diubah menjadi struct lisette.Option dan lisette.Result
  • Sintaks match diubah menjadi pernyataan kondisional Go untuk menangani tiap cabang
  • Operator ? secara internal diganti dengan kode pemeriksaan Result
• Sebagai contoh, fungsi classify menerima Option<int> lalu diubah menjadi pernyataan kondisional eksplisit di Go, sedangkan fungsi combine diubah menjadi kode Go yang memeriksa Result

Informasi tambahan

• Repositori resmi: github.com/ivov/lisette
• Dirilis dengan lisensi MIT, dan pada 2026 dikembangkan oleh Iván Ovejero

[GN⁺]

Komentar Hacker News

• Saya sempat berbincang dengan pembuatnya dan meski belum mencoba bahasanya secara langsung, Lisette tampak menarik dan jelas merupakan perbaikan dibanding Go
  Meski begitu, saya rasa sulit untuk sepenuhnya mengatasi keterbatasan Go. Misalnya, masalah typed nil yang berasal dari tipe interface di Go ditangani dengan Option di Lisette, tetapi unwrapping ganda (Some(Some(h))) bisa terasa canggung
  Selain itu, pendekatan defer di Go tetap tidak nyaman, dan tidak menyediakan pelepasan resource otomatis seperti RAII
  Alasan TypeScript melengkapi JavaScript adalah karena tidak ada alternatif yang bisa dijalankan di browser, tetapi sekarang situasinya berbeda karena ada WASM
  Jadi muncul pertanyaan, “kalau sudah ada Rust, kenapa membuat Go menjadi seperti Rust?” Meski begitu, Lisette tampaknya membidik titik tengah di antaranya
  Pada akhirnya, Lisette terlihat cocok untuk orang yang ingin memperbaiki codebase Go yang sudah ada atau tetap ingin memakai runtime Go
  Yang membuat saya penasaran adalah tidak adanya panduan mulai cepat untuk pertanyaan “bagaimana cara mulai menulis file berikut ini dengan Lisette alih-alih Go”
  Tulisan blog terkait: Go is still not good

  • Go masih unik karena menyediakan runtime konkurensi berbasis GC
    Di domain masalah yang menangani grafik referensi kompleks, GC itu esensial, dan berkat struktur stack mode pengguna di Go, ia punya model memori yang efisien
  • Di bahasa ber-GC, kecepatan pengembangan jauh lebih tinggi. Saya pernah membuat chatbot dengan Rust dan Python, dan meski punya pengalaman Rust, Python jauh lebih cepat
    Go juga cocok untuk membuat alat CLI cepat seperti ini — contoh: wordle-tui
  • Go punya banyak keanehan sebagai bahasa, tetapi sangat bagus sebagai target kompilasi
    Sintaksnya sederhana, dukungan lintas platform bagus, runtime dan GC sudah tertanam, ada pola “errors as values”, green thread, kompiler AOT yang cepat, dan banyak keunggulan lain
    defer di Go memang berguna, tetapi penanganan error dan aturan scope terasa canggung
  • Ungkapan di blog bahwa “Go adalah bahasa yang secara tidak sengaja menciptakan NULL dua kali” terasa sangat membekas
    TypeScript juga gagal menyelesaikan masalah ini, malah lebih buruk. Karena itu saya membuat sendiri paket tipe Option dan mengunggahnya ke NPM → fp-sdk
  • async di Rust kurang nyaman dibanding Go karena tidak ada GC. Hanya karena poin ini saja, runtime Go sudah punya alasan untuk dipilih

• Sudah ada beberapa bahasa yang dikompilasi ke Go — XGo, Borgo, Soppo, dan lainnya

  • Borgo dan Lisette sama-sama hanya mengganti return (T, error) menjadi tipe Result, tetapi secara makna keduanya tidak sepenuhnya sama
    Misalnya, io.Reader.Read memakai (n!=0, io.EOF) untuk menandakan akhir normal, jadi kalau diperlakukan begitu saja sebagai error, perilakunya akan jadi salah
  • Saya penasaran bagaimana error kompilasi disampaikan dari bahasa target ke bahasa sumber

• Kualitas pesan error di Lisette sangat mengesankan. Petunjuk “help”-nya terasa benar-benar berguna
  Namun, karena kode yang diubah ke Go bisa menjadi verbose, saya khawatir saat error runtime terjadi kita harus melakukan debugging di kode Go
  Selain itu, arah memanggil Lisette dari kode Go yang sudah ada tampak sulit
  Saya juga penasaran apakah Lisette adalah bahasa eksperimental atau memang ditujukan untuk produksi nyata

  • Pengembangnya menjawab langsung: bila memakai opsi lis run --debug, komentar //line source.lis:21:5 akan disisipkan ke kode Go sehingga stack trace dipetakan ke kode Lisette asli
    LSP menangani error waktu kompilasi berdasarkan file .lis
    Saat ini belum ada fitur memanggil Lisette dari Go, tetapi prioritasnya adalah mengimpor paket Go dari Lisette
    Awalnya ini hanya eksperimen, tetapi tujuannya adalah mengembangkannya menjadi bahasa tingkat produksi

• Saya penasaran kenapa sintaks yang mirip Rust tidak diambil apa adanya
  Contoh: memakai use foo::bar alih-alih import "foo.bar", atau Bar::Baz => alih-alih Bar.Baz =>
  Orang yang tahu Rust bisa bingung, dan yang tidak tahu Rust juga tidak mendapat transfer pengetahuan ke Rust

  • Perbedaan sintaks seperti ini hal kecil; inti utamanya adalah membawa sistem tipe Rust ke Go
    int dan float64 mengikuti konvensi penamaan tipe milik Go
  • Kalau sering berpindah-pindah bahasa, kemiripan sintaks justru bisa menimbulkan kebingungan. Misalnya, saya sering lupa bahwa di PHP harus memakai . alih-alih +
  • Saya juga awalnya ingin membuat bahasa bergaya Rust berbasis TypeScript, tetapi akhirnya sadar bahwa Rust sendiri tidak sesulit yang saya kira
  • Menerapkan model memori gaya Rust pada bahasa ber-GC itu sangat tidak alami. Rasanya seperti setiap objek punya ruang alamat yang terpisah, jadi rumit
  • Lisette adalah bahasa yang terinspirasi dari Rust, bukan berusaha menjadi Rust. Target utamanya adalah pengembang Go

• Runtime Go itu bagus, tetapi bahasanya sendiri terasa kasar dan tampaknya tidak punya keinginan untuk berkembang
  Jadi kalau sampai memakai transpiler, sepertinya memang harus benar-benar tidak suka Go

• Saya penasaran kenapa Rust atau bahasa keluarga Rust memisahkan struct dan method
  Kenapa method tidak bisa didefinisikan langsung di dalam struct

  • Di Rust, field struct memengaruhi auto-trait, jadi penting untuk bisa melihat field sekaligus dalam satu pandangan
    Selain itu, blok impl bisa punya constraint generic yang berbeda dari struct-nya, jadi bisa didefinisikan lebih dari satu
    Terakhir, Rust adalah bahasa yang dirancang agar orang berpikir dengan berpusat pada bentuk (shape) data
  • Secara pribadi, saya merasa blok impl mirip dengan method di Go, dan saya tidak yakin salah satunya jelas lebih baik

• Kalau ada bahasa yang terlihat seperti Python tetapi dikompilasi ke Rust atau Go, itu akan sangat keren

  • Mojo adalah bahasa performa tinggi dengan sintaks Python yang dibuat oleh pencipta Swift
  • Spy adalah upaya awal yang dikompilasi ke C, dan Nim juga bahasa matang di keluarga yang mirip
  • Nim punya sintaks yang mirip Python dengan sistem tipe statis, dan dikompilasi ke berbagai target seperti wasm dan C
  • Static Python Skill adalah upaya untuk mengompilasi Python secara statis
  • Grumpy adalah transpiler Python→Go buatan Google, tetapi sudah 9 tahun tidak diperbarui (menargetkan Python 2.7)

• Lisette tampak seperti bahasa yang berhasil menyeimbangkan kesederhanaan Go dan kompleksitas Rust
  Saya penasaran apakah ada alasan kenapa kecepatan kompilasinya harus jauh lebih lambat daripada Go, dan bagian mana dari fitur Rust yang sengaja dikecualikan
  Contohnya: borrow checking, tipe data, async, dan sebagainya

• Go adalah bahasa yang mudah dipelajari, tetapi fiturnya kurang
  Lisette tampak menarik karena menjadi bahasa yang mengisi celah itu
  Seperti TypeScript memperluas JavaScript, kalau Go diberi sistem tipe yang lebih ekspresif dan kompiler yang lebih ketat, ia bisa menjadi bahasa backend yang hebat
  Saran pribadi saya adalah mendukung berbagi tipe dengan frontend TypeScript. Ini salah satu alasan TypeScript populer juga di backend

• Sebagai pengembang otomatisasi infrastruktur yang bimbang antara keamanan Rust dan kesederhanaan Go, ide menghadirkan kemudahan penggunaan Rust di atas runtime Go terasa sangat menarik
  Saya akan terus mengikuti perkembangan proyek ini