Kembali ke Zig — Zig → Rust → Zig

• Zig berawal sebagai bahasa tingkat rendah yang berupaya mengurangi ketidaknyamanan C, dan kini layak ditinjau kembali berkat filosofi seperti alokasi memori eksplisit dan tidak adanya alur kontrol tersembunyi
• Rust pernah menjadi alternatif praktis untuk keluar dari perubahan Zig yang sering dan ekosistemnya yang belum matang, tetapi menunjukkan keterbatasan pada aspek seperti FFI, kompilasi silang, dan alokasi tersembunyi
• Keputusan untuk kembali ke Zig dipengaruhi bukan hanya alasan teknis, tetapi juga turunnya kepercayaan terhadap proyek Rust terkait tata kelola dan kebijakan kode yang dihasilkan LLM
• Zig pada 2026 masih tidak stabil dan Zig 0.17.0 direncanakan akan merusak sistem build, tetapi nuansa bahasanya tidak jauh berbeda dari 2020 dan pengalaman manajemen paketnya membaik
• Alih-alih menawarkan keamanan memori waktu kompilasi ala Rust, Zig memilih keseimbangan antara kesederhanaan dan keamanan runtime melalui filosofi ReleaseSafe, pengujian, fuzzing, dan assertion

---

Titik awal ketertarikan pada Zig

• Pertama kali mengenal Zig pada 2020; saat itu terlihat seperti bahasa baru kecil dengan eksekusi kode saat compile-time dan abstraksi sederhana
• Saat belajar C, rasa mengendalikan komputer secara langsung terasa menyenangkan, tetapi abstraksi lama dan tooling yang kurang memadai terasa merepotkan
• Meski baru dan tidak stabil, Zig menjanjikan pengganti C, dan daya tariknya adalah bisa mempelajari “bahasa berikutnya”
• Software Should Be Perfect dari Andrew Kelley membentuk standar dalam memandang bahasa pemrograman dan perangkat lunak
  • Alokasi memori eksplisit yang dapat gagal
  • Tidak ada alur kontrol tersembunyi
  • Reusability universal
• Setelah membuat bahasa pemrograman mainan, alat literate programming, dan server web dengan Zig, bahasa ini terasa lebih nyaman daripada C tetapi dengan lebih sedikit faktor risiko

Alasan berpindah ke Rust

• Kode Zig sering rusak, dan sebagai mahasiswa tidak ada cukup waktu untuk terus memperbaiki proyek agar sesuai dengan versi bahasa terbaru
• Saat itu belum ada anyzig, sehingga sulit menangani beberapa versi Zig dengan mudah di satu sistem
• Jika kembali ke sebuah proyek setelah beberapa bulan, kadang perlu melakukan refactor besar yang tidak sepenuhnya dipahami agar proyek berjalan lagi
• Ekosistemnya juga masih kecil
  • Sebagai programmer baru, belum punya kemampuan untuk mengimplementasikan sendiri semua yang dibutuhkan
  • Library dan contoh masih sedikit
  • Standard library terus berubah
  • Dokumentasi dasar pun belum stabil
• Rust sudah distabilkan selama bertahun-tahun dan memiliki ekosistem yang kuat
• Mempelajari Rust memang sulit, tetapi setelah dikuasai, kode berjalan stabil, dan stabilitas itu penting
• Rust adalah bahasa cepat dan tingkat rendah yang menyediakan ekspresivitas yang dibutuhkan, sekaligus mengurangi biaya akibat ketidakstabilan yang dialami di Zig
• Rust membantu membentuk model memori yang tetap berguna bahkan saat memakai bahasa dengan lebih sedikit pemeriksaan bawaan
• Pada kode tanpa panic, kita bisa menulis kode reusable tanpa alur kontrol tersembunyi atau garbage collector
• Namun Rust juga punya sisi yang menyembunyikan alokasi memori dan membuat pekerjaan dengan C menjadi sulit

Ketidakpuasan yang membuat Zig dilirik lagi

• Rust bukan bahasa sempurna untuk membuat program reusable yang diinginkan
  • FFI sulit
  • Kompilasi silang merepotkan
  • Alokasi memori tersembunyi yang diperlakukan seolah tidak gagal terasa membebani
  • Karena terikat pada LLVM, mungkin butuh waktu lama atau bahkan mustahil mendukung platform sebanyak C
• Tata kelolanya juga tetap menjadi titik yang kurang nyaman
  • Rust Foundation memiliki beberapa foundation members dari perusahaan raksasa
  • Jika perusahaan-perusahaan terbesar di dunia memberikan ratusan ribu dolar setiap tahun, ada kemungkinan arah pengembangan Rust terpengaruh
• Banyaknya proyek komunitas open source yang mulai menerima kode hasil LLM menjadi kejutan tersendiri
• Di berbagai proyek, maintainer dan pengguna menulis atau menuntut kebijakan LLM
• Zig sepenuhnya melarang LLM dalam proyeknya
• Rust menjalankan survei dan sentimen komunitas secara umum anti-LLM, tetapi tidak langsung membuat kebijakan resmi
• Usulan kebijakan Rust memuat klausul yang melarang topik berikut disebutkan dalam komentar PR
  • Dampak sosial dan ekonomi jangka panjang dari LLM
  • Dampak lingkungan LLM
  • Status hak cipta output LLM
  • Penilaian moral terhadap pengguna LLM
• Klausul itu dihapus setelah mendapat penolakan, tetapi fakta bahwa klausul tersebut pernah ada saja sudah menurunkan kepercayaan terhadap proyek Rust
• Kebijakannya sendiri pada umumnya membatasi LLM dan mengurangi slop, sehingga dinilai cukup baik
• Pengalaman ini menjadi pemicu untuk kembali meninjau Zig secara serius setelah beberapa tahun

Zig pada 2026

• Zig masih tidak stabil
• Sempat mencoba memulai dari contoh Zig 0.16.0 yang ditemukan di web, tetapi contoh itu sudah usang
• Agar produktif bekerja dengan Zig, cara terbaik adalah menyimpan salinan source standard library di dekat kita dan membiasakan diri dengannya
• Zig 0.17.0 akan segera dirilis dan direncanakan akan merusak sistem build semua proyek
• Para maintainer berusaha bergerak menuju stabilisasi, dan kerusakan seperti ini adalah bagian dari proses tersebut
• Untungnya, bahasa itu sendiri tidak banyak berubah sejak 2020
  • Sebagian besar intuisi masih berlaku
  • Sebagian library telah dikerjakan ulang, tetapi kodenya mudah dibaca
  • Kode Zig saat ini pun diperkirakan masih bisa dikenali enam tahun kemudian
• Kini Zig memiliki package manager
  • Dulu, seingatnya, pengelolaan dependency menggunakan git submodule
  • Tool bawaan jauh lebih baik
  • Proyek dapat mendefinisikan dependency melalui git dan tarball
  • Vendoring bekerja dengan mudah
• Ekosistemnya masih belum besar, tetapi ekosistem besar juga bukan tujuan yang dikejar Zig
• Tidak ada registry paket resmi, dan posisinya adalah tidak membutuhkan NPM atau crates.io lain
• Zig saat ini dinilai telah mencapai keseimbangan yang tepat

Cara memandang keamanan memori

• Zig tidak menyediakan jaminan keamanan memori seperti Rust
• Ini adalah trade-off demi kesederhanaan, dan kompleksitas affine type di Rust dinilai tidak selalu sepadan dengan manfaat keamanannya
• Namun bukan berarti Zig menyerah pada keamanan
• Dari sudut pandang Zig is safer than unsafe Rust, Zig bisa menjadi pilihan lebih baik dalam situasi yang mengharuskan penggunaan unsafe Rust
• Zig juga sedang mengerjakan upaya untuk membuat bahasanya lebih aman
  • Pendekatannya berfokus pada mode rilis, bukan area kode unsafe
  • Saat ini mode ReleaseSafe Zig akan crash ketika assertion gagal dan menginisialisasi seluruh memori
  • Andrew Kelley tertarik pada arah untuk memasukkan sesuatu seperti Fil-C ke ReleaseSafe
• Cara ini memang tidak memberikan keamanan memori waktu kompilasi Rust saat unsafe dihindari, tetapi ini tidak dianggap sebagai death spiral seperti yang dikatakan sebagian orang
• Keamanan memori adalah spektrum, dan tidak ada satu pendekatan yang paling baik untuk semua situasi
• Pendekatan Zig adalah membuat ReleaseSafe seaman mungkin saat runtime, lalu memastikan kebenaran lewat pengujian dan fuzzing
• Illegal behavior yang tidak diperiksa harus ditemukan dalam proses ini, dan setelah kebenaran terbukti, binary dari mode rilis lain dapat didistribusikan dengan aman
• Cara ini memiliki kekurangan dibanding model Rust, tetapi dalam arah Zig yang sangat menekankan kesederhanaan, tidak dianggap secara mutlak lebih inferior
• Jika keamanan memori waktu kompilasi cukup penting hingga layak membayar biaya sistem tipe yang kompleks dan waktu kompilasi panjang, maka Rust bisa dipilih
• Model keamanan memori Zig juga tersambung dengan filosofi assertion
  • Alih-alih menonaktifkan assertion di ReleaseFast, kita percaya bahwa pengujian telah membuktikan assertion itu benar dan jalur tersebut unreachable
  • Ini memungkinkan Zig mengoptimalkan kode
  • Tulisan terkait: your assertions are correct

Arah penggunaan ke depan

• Siap menangani masalah perangkat lunak dengan Zig sambil menaruh standard library dan catatan perubahan rilis di sisi kita
• Saat tidak ingin berurusan dengan detail tingkat rendah, akan menggunakan bahasa scripting favorit
• Untuk perangkat lunak ke depan, Zig direncanakan menjadi alat utama
• Tetap terbuka kemungkinan untuk tidak terus menetap di Zig
  • Jika membutuhkan stabilitas atau sistem tipe Rust, Rust dapat digunakan
  • Pandangan terhadap pendekatan Zig juga bisa berubah sepenuhnya
  • Banyak bahasa dapat, dan seharusnya, hidup berdampingan
• Zig mewakili visi perangkat lunak yang berfokus pada pengguna dengan menerima, bukan mengabaikan, kualitas perangkat lunak
• Orang berhak mendapatkan perangkat lunak yang dapat dipercaya dan kuat, dan di era LLM, perangkat lunak yang dibuat dengan sungguh-sungguh dianggap semakin langka sementara orang-orang ditekan untuk menerima slop yang makin buruk

[clastneo]

Saya pernah berhenti mempelajari Zig setelah mendengar kabar bahwa versi baru akan segera keluar saat sedang belajar.
Kalau versi stabil sudah dirilis, mungkin layak dimasukkan lagi ke daftar belajar, tetapi sampai sekarang breaking changes-nya masih terlalu banyak sehingga saya takut untuk mulai menyentuhnya.

[click]

Zig terus membuang kompatibilitas ke belakang setiap kali mengubah spesifikasi bahasanya, jadi menurut saya bahasa ini sulit dipakai untuk sistem penting setidaknya sampai versi 1.0 dirilis.
Sepertinya ghostty cukup kerepotan karena perubahan pada std.IO: isu
Sebagai contoh dari bahasa lain, andaikan di Java, setelah Future muncul, API JDBC berubah menjadi mengembalikan Future atau CompletableFuture, jelas akan ada kemajuan besar, tetapi sebagai gantinya pasti akan menimbulkan kekacauan yang luar biasa.

[GN⁺]

Komentar di Lobste.rs

• Suatu hari ingin mencoba Zig lagi
  Sebenarnya sangat ingin mencobanya, tetapi sejauh ini sibuk dengan hal-hal lain
  Terakhir kali menyentuh Zig, dalam sekitar 3 jam saya menemui error compiler, dan itu cukup membekas. Agar adil, bug itu saat itu sudah diperbaiki di branch terbaru

• Saya meragukan pernyataan bahwa “karena terikat pada LLVM, butuh waktu sangat lama atau bahkan tidak akan pernah bisa mendukung platform sebanyak C”
  Saya penasaran platform apa yang tidak didukung LLVM yang ingin dijadikan target pengembangan, dan bagaimana Zig lebih baik dalam hal ini
  Saya ingin bertanya apakah maksudnya Zig menghasilkan kode C tier-4, lalu GCC bisa mengompilasinya untuk hppa, alpha, dan sh

  • Sejauh yang saya pahami, Zig sedang aktif mengerjakan pengurangan ketergantungan pada LLVM, jadi ke depannya saat mengimplementasikan target baru di compiler Zig, mungkin tidak perlu menyentuh proyek LLVM itu sendiri
  • Saat ini, pembuatan kode C adalah cara implementasinya
    Masalahnya, Zig memiliki backend resmi selain LLVM, sedangkan Rust menggunakan LLVM
    Jika sebuah bahasa sistem ingin memaksimalkan keterpakaiulangan perangkat lunak, ia harus bisa berjalan seluas mungkin; apalagi jika tujuannya, seperti Zig, adalah menggantikan C
  • Dari ingatan samar saya, fokus kekhawatirannya sepertinya lebih dekat ke waktu kompilasi daripada dukungan platform

• Melihat keberhasilan ghostty, saya berencana mencoba Zig untuk pengembangan game setelah mencapai 1.0
  Namun saya tidak benar-benar yakin apakah jenis game yang saya buat membutuhkan performa sebesar itu

  • Jika Anda mengenal Godot, Anda bisa mencoba https://github.com/godot-zig/godot-zig

• Pernyataan semacam “Zig tidak mengorbankan keamanan, dan lebih aman daripada unsafe Rust. Jika pada akhirnya harus memakai unsafe Rust, Zig bisa jadi lebih baik” cukup sering terdengar, tetapi setiap kali melihatnya saya kurang bisa memahaminya
  Terutama karena penulis mengakui bahwa keamanan adalah spektrum, tetapi tetap menyarankan beralih ke bahasa yang semuanya terus-menerus unsafe alih-alih memakai area unsafe yang terlokalisasi
  Mesin abstraknya mungkin sedikit lebih mudah dinalar, tetapi pertukaran itu tidak terasa meyakinkan