Perombakan ulang resolusi tipe dan perubahan bahasa

 (ziglang.org)
1 poin oleh GN⁺ 2026-03-12 | 1 komentar | Bagikan ke WhatsApp
  • Logika resolusi tipe (type resolution) di kompiler Zig dirombak total, sehingga struktur internalnya menjadi lebih sederhana dan menghadirkan peningkatan yang juga terlihat oleh pengguna
  • Desain baru menangani analisis field tipe secara lazy, sehingga tidak memeriksa detail struktur tipe yang belum diinisialisasi secara tidak perlu
  • Pesan kesalahan dependency loop diperbaiki secara lebih spesifik, sehingga penyebab loop dapat dipahami dengan jelas
  • Masalah analisis berlebihan pada fitur incremental compilation dan banyak bug telah diperbaiki, sehingga kecepatan build meningkat signifikan
  • Perubahan kali ini mencakup puluhan perbaikan bug dan penyempurnaan kecil pada bahasa, yang secara keseluruhan memperkuat performa dan pengalaman pengembangan kompiler Zig

Perombakan ulang logika resolusi tipe

  • Sebuah PR berukuran sekitar 30 ribu baris telah di-merge, menulis ulang logika resolusi tipe di kompiler Zig menjadi struktur yang lebih logis dan intuitif
    • Dalam proses ini, struktur internal kompiler dirapikan, dan pengguna juga merasakan dampak perbaikannya secara langsung
  • Kompiler diubah agar melakukan evaluasi lazy pada analisis field tipe, sehingga tidak lagi menelusuri detail struktur tipe yang belum diinisialisasi secara tidak perlu
    • Pada contoh kode, jika sebuah struct yang berisi field @compileError hanya digunakan sebagai namespace, sebelumnya akan memicu kesalahan kompilasi, tetapi sekarang dapat dikompilasi dengan normal
    • Ini mencegah dependensi kode yang tidak perlu saat memakai tipe berbentuk namespace seperti std.Io.Writer

Peningkatan pesan kesalahan dependency loop

  • Sebelumnya, pesan kesalahan dependency loop cenderung ambigu, tetapi sekarang penyebab dan lokasinya ditampilkan dengan jelas
    • Pada contoh kode ketika struct Foo dan Bar saling mereferensikan, pesan kesalahan kini menunjukkan secara spesifik lokasi dependensi tiap tipe
    • Pesan tersebut mencakup panjang loop, lokasi deklarasi tiap field, dan lokasi kueri alignment
  • Bahkan pada loop yang kompleks, informasi yang diberikan cukup untuk memudahkan identifikasi akar masalah

Peningkatan performa incremental compilation

  • Perubahan kali ini memperbaiki banyak bug pada fitur incremental compilation
    • Secara khusus, masalah “over-analysis” diselesaikan sehingga hanya bagian yang berubah yang dikompilasi ulang
    • Hasilnya, dalam banyak kasus kecepatan kompilasi meningkat signifikan
  • Pengembang dapat mengaktifkan incremental compilation di Zig versi 0.15.1 atau lebih baru untuk merasakan pengalaman pengembangan yang telah ditingkatkan

Peningkatan lainnya

  • PR ini juga mencakup puluhan perbaikan bug, perubahan kecil pada bahasa, dan peningkatan performa kompiler
    • Sebagian besar terkait detail kecil atau kasus yang bersifat khusus
  • Rincian perubahan lengkap dapat dilihat di Codeberg melalui PR #31403
  • Jika menemukan bug baru, pengguna dianjurkan untuk melaporkan issue

Makna perubahan ini

  • Dengan penyederhanaan logika resolusi tipe dan optimalisasi incremental compilation, stabilitas dan efisiensi kompiler Zig semakin diperkuat
  • Pengembang akan menerima umpan balik yang lebih cepat dan jelas, serta dapat mengharapkan peningkatan produktivitas bahkan pada codebase besar

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-12
Komentar Hacker News

  • Saya adalah penulis devlog ini
    Saya memahami kekhawatiran soal breakage kompatibilitas akibat perubahan bahasa, tetapi saya ingin menegaskan bahwa perubahan compiler kali ini tidak sampai menimbulkan dampak besar
    Sebagai contoh, saat membangun ZLS dengan branch baru, perubahan yang diperlukan hanya mengganti .{} menjadi .empty. Ini karena penghapusan nilai default std.ArrayList, yang sebenarnya sudah berstatus deprecated sejak 1 tahun lalu
    Untuk proyek Awebo juga, hanya ada tiga hal yang perlu diperbaiki di seluruh pohon dependensi — perubahan .empty, penambahan comptime, dan penambahan orelse @alignOf(T)
    Sebagian besar perbaikan ini adalah perubahan sederhana yang bagi kebanyakan developer Zig bisa ditangani secara refleks
    Inti dari PR ini bukanlah breakage, melainkan perbaikan bug dan peningkatan incremental compilation

    • Saya adalah salah satu penulis komentar yang tampak kritis terhadap perubahan ini
      Saya menilai kualitas dan perencanaan PR ini sangat tinggi, dan sama sekali tidak bermaksud meremehkan upaya penulisnya
      Namun saya juga mendapat pelajaran bahwa ke depan saya harus memberi lebih banyak konteks dan menuliskan pendapat dengan lebih hati-hati
    • Saya tidak terlibat langsung dengan Zig, tetapi setelah melihat komentar yang ditambahkan ke lib/std/multi_array_list.zig, saya jadi penasaran
      Saya tidak paham kenapa penggunaan @alignOf(T) dalam definisi MultiArrayList(T) bisa menimbulkan dependensi siklik
      Bahkan jika T adalah MultiArrayList itu sendiri, bukankah itu tetap tipe monomorfik yang sepenuhnya terpisah? Mungkin saya melewatkan sesuatu
      Kode terkait: tautan

  • Saya penasaran dengan pengalaman orang-orang yang menggunakan Zig di lingkungan production
    Bahasanya sering berubah, jadi saya ingin tahu seperti apa siklus update atau rewrite-nya, dan apakah ada kasus paket dependensi tertinggal dari versi bahasa
    Saya tahu Bun memanfaatkan Zig dengan baik, tetapi saya juga ingin mendengar contoh lain

    • Saya mengelola codebase compiler Zig sekitar 250 ribu LoC (roc-lang/roc)
      Dalam 1~2 tahun terakhir, perubahan pada bahasa dan standard library berjalan tanpa masalah besar
      Dulu upgrade memang merepotkan, tetapi sekarang rasanya hanya sebatas “sedikit tidak nyaman”
      Jika ditanya soal pengalaman memakai Zig, bagian ini bahkan hampir tidak saya sebut karena sudah cukup stabil
    • Saya pernah bekerja pada dua codebase Zig production, tigerbeetle dan sig
      Proyek-proyek besar seperti ini melakukan upgrade berdasarkan tagged release, dan biasanya menyelesaikan migrasi dalam beberapa hari hingga beberapa minggu
      Dependensinya juga sangat sedikit, jadi beban upgrade tidak terlalu besar
    • Zig 0.15 cukup stabil
      Hanya saja, typo kecil kadang bisa memicu SIGBUS compiler crash, sehingga debugging jadi sulit
      .zig-cache pernah membesar sampai 173GB dan menyebabkan masalah pada ARM VPS
      Saat menaikkan lightpanda dari 0.14 ke 0.15, prosesnya lancar. Sepertinya 0.16 juga tidak akan membawa masalah besar
      Tetapi sebagai developer library, sulit mengikuti laju perubahan cepat di 0.16
      Saat ini saya hanya menanganinya secara eksperimental di branch “dev”
    • Saya menjalankan sekitar 20 ribu LoC kode Zig 0.16 di production dalam DebugSafe mode
      Saya me-rewrite modul Node.js/TypeScript ke Zig, dan hasilnya 2x lebih cepat dengan penggunaan memori turun 70%
      Dukungan sqlite/serialisasi JSON di Zig adalah keunggulan besar
      Kekurangannya adalah tidak adanya sintaks closure atau vtable, sehingga lebih sulit memisahkan lapisan kode
      Saya memakai Arcs dan bumper allocator untuk menjaga keamanan memori, dan berencana terus menjalankannya dalam DebugSafe mode
      Beralih ke ReleaseFast memang memberi peningkatan sekitar 25%, tetapi tidak sebanding dengan hilangnya aspek keamanan
    • Saya rasa janji kompatibilitas mundur abadi di C++ justru merupakan kesalahan yang menghambat perkembangan bahasa
      Walaupun kode harus diperbaiki, dalam jangka panjang ini adalah pendekatan yang benar

  • Saya terkesan dengan hasil kerja tim Zig
    Saya sering memakai terminal ghostty yang dibuat dengan Zig, dan sangat stabil
    Namun secara pribadi saya lebih memilih Rust
    Rust mengambil model “closed world”, sedangkan Zig mengambil model “open world”
    Rust mengharuskan trait diimplementasikan secara eksplisit, sedangkan di Zig cukup jika shape dari tipe tersebut sesuai
    Ini membuat Zig memungkinkan metaprogramming yang kuat, tetapi type inference menjadi tidak jelas sehingga autocomplete, dokumentasi, dan dukungan LSP menjadi lebih sulit

    • Saya penasaran dengan contoh konkret
      Dari penjelasannya, ini terdengar mirip dengan interface di Go, tetapi setahu saya Zig tidak punya konsep padanan langsung untuk itu

  • Peralihan dari kernel32 ke Ntdll menarik
    Ini adalah konsep yang juga bisa diterapkan pada API user-space Linux
    Terutama, cara penanganan error di batas kernel-user terasa mirip
    Hanya saja di Linux, libc dan kernel sangat saling terikat sehingga penggunaan errno menjadi wajib
    Saya penasaran kenapa pola seperti ini juga muncul di Windows

    • Pola errno atau GetLastError() adalah warisan dari era sebelum thread
      Dulu penjadwalan bersifat kooperatif sehingga variabel global aman, tetapi saat multicore dan thread muncul, itu menjadi berbahaya
      Karena itu thread local kemudian muncul sebagai alternatif

  • Daripada memakai tipe seperti namespace, saya merasa mungkin lebih baik jika bahasa ini menambahkan namespace eksplisit

    • Zig menganut minimalisme bahasa
      Jika sebuah fitur memberi optimasi di banyak tempat, maka fitur itu baru akan ditambahkan saat benar-benar perlu
    • Sebenarnya ini bukan workaround, melainkan keanggunan desain
      Di Zig, @import mengubah file menjadi struct, dan namespace direpresentasikan hanya sebagai struct bertingkat
      Artinya, namespace tidak lebih dari import lain
      (Kopi saya belum sepenuhnya masuk, jadi saya tidak menjamin akurasinya)

  • Ada bagian yang sering terlewat dalam diskusi perubahan bahasa — yaitu dampaknya pada ekosistem
    Jika bahasa sering mengalami breakage, bukan hanya aplikasi tetapi juga library, tool, dan tutorial yang harus terus mengejar perubahan
    Akibatnya, ekosistem akan cenderung berpihak pada proyek yang aktif dipelihara, alih-alih library yang “sekali dibuat lalu dibiarkan”
    Ini mungkin trade-off yang masuk akal pada tahap awal desain bahasa, tetapi dalam jangka panjang akan memengaruhi pertumbuhan ekosistem
    Bahasa-bahasa baru lain banyak berupaya meminimalkan kelelahan akibat perubahan semacam ini
    Akan menarik untuk melihat hasil dari pendekatan Zig

    • Contohnya adalah ekosistem addon Blender
      Blender sering memecahkan API, tetapi kebanyakan perbaikannya kecil
      Tetap saja, seseorang harus memperbaikinya, dan jika maintenance berhenti, pengguna harus mem-patch sendiri
      Addon berbayar memang lebih mungkin terus dipelihara, tetapi itu pun bukan jaminan
    • Menurut saya Zig tetap layak untuk itu
      Library yang tidak dipelihara pada dasarnya memang kode buruk
      Daripada terus mengkritik Zig, lebih baik berhenti mempromosikan bahasa lain (seperti C3)

  • Klaim di PR Zig bahwa “Chromium, boringssl, Firefox, Rust memanggil SystemFunction036 dari advapi32.dll” sebenarnya tidak benar
    Mereka sudah memakai ProcessPrng, dan sejak Windows 10 ini tidak pernah gagal
    Dasarnya ada di whitepaper Microsoft
    Permintaan RNG dirancang agar sama sekali tidak bisa gagal, dan jika gagal maka prosesnya sendiri akan dihentikan
    Jadi, demi menjamin bilangan acak berkualitas tinggi, API ini tidak mengembalikan kode error

    • (Ini adalah balasan untuk devlog lain di halaman yang sama)

  • Semantik bahasa Zig tampak sederhana di permukaan, tetapi interaksinya cukup subtil
    Hal seperti ini terasa bisa menghasilkan corner case kompleks seiring waktu, seperti aturan template C++

  • PR 30 ribu baris adalah pencapaian besar
    Namun mengubah semantik bahasa adalah hal yang sangat besar, jadi saya cukup terkejut
    Saya paham Zig masih sebelum 1.0 sehingga perubahannya cepat, tetapi ungkapan yang terasa kasual seperti “kami mengubah semantik di branch ini” sedikit mengejutkan
    Saya jadi penasaran apakah perubahan skala besar seperti ini memang budaya khas Zig, atau justru saya yang tertinggal zaman
    Ungkapan “modern Zig” juga terasa lucu karena cepatnya laju perubahan bahasa ini

    • Jangan menganggap gaya penulisan yang kasual berarti sikap yang sembrono
      Devlog bukan tulisan pemasaran, melainkan lebih mirip catatan internal untuk orang dalam, dan Zig memang belum 1.0
      PR tersebut memuat konteks dan alasan yang cukup
      Saat memilih Zig, pada dasarnya kita sudah menerima tingkat tertentu dari risiko perubahan bahasa
      Justru merapikannya dengan bersih sekarang akan lebih menguntungkan dalam jangka panjang
      (Bayangkan warisan yang tidak bisa diperbaiki seperti prioritas operator bitwise di C)
    • mlugg adalah kontributor inti Zig sekaligus anggota Zig Foundation
      Perubahan kali ini adalah upaya untuk mengatasi dependensi siklik dan merapikan sistem tipe
      Proposal terkait sudah dipublikasikan di #3257 dan #15909
      Dengan perubahan ini, resolusi tipe di Zig ditata ke struktur DAG (directed acyclic graph), sehingga stabilitas compiler meningkat drastis
      Zig dikelola dengan model BDFN (Benevolent Dictator For Now), dan keputusan akhir ada pada Andrew Kelley
      Namun timnya adalah organisasi nirlaba yang menempatkan kepercayaan pengguna dan kualitas bahasa sebagai prioritas tertinggi
      Secara pribadi, bisa bekerja bersama Matthew adalah kehormatan besar
    • Mungkin sikap seperti ini merupakan hasil belajar dari sejarah bahasa C yang kacau
      Secara formal tampak rapi, tetapi dalam praktiknya C adalah bahasa yang penuh kekacauan