Backend x86 self-hosted kini menjadi default di mode debug

• Kini untuk target x86_64, backend x86 milik Zig sendiri diterapkan sebagai default di mode debug
• Mencapai lebih banyak tes perilaku yang lolos dan kecepatan kompilasi yang lebih cepat dibanding basis LLVM sebelumnya
• Dengan adopsi backend internal, waktu kompilasi Zig berkurang drastis dan efisiensi beberapa pekerjaan meningkat
• Berbagai peningkatan fitur juga sedang berlangsung, termasuk sistem build yang baru-baru ini disempurnakan, perluasan dukungan OS keluarga BSD, serta peningkatan runtime UBSan
• Menekankan daya saing khas Zig melalui optimalisasi standard library dan alat internalnya sendiri

---

Ringkasan kabar utama terbaru

8 Juni 2025 – backend x86 self-hosted beralih menjadi default di mode debug

• Untuk target x86_64, kini secara default digunakan backend x86 milik Zig sendiri
  • Sebelumnya, LLVM digunakan untuk mengubah bitcode menjadi file objek
  • Di Windows, perubahan ini masih ditunda karena pekerjaan tambahan pada linker COFF masih diperlukan
• Backend x86 Zig telah lulus 1.987 tes perilaku, menunjukkan stabilitas yang lebih kuat dibanding backend LLVM (1.980 tes)
  • Total tes ada 2.084, tetapi sebagian tumpang tindih dengan tes internal LLVM, sehingga verifikasi tambahan hanya dilakukan saat menguji backend internal
• Alasan utama Zig berfokus mengembangkan code generator internal adalah untuk melampaui LLVM secara signifikan dalam kecepatan build
  • Berdasarkan hasil benchmark, rata-rata waktu build zig build-exe hello.zig -fllvm (menggunakan LLVM) adalah 918ms, sedangkan backend internal mencatat 275ms
  • Dalam semua aspek seperti penggunaan memori, siklus CPU, jumlah instruksi, dan cache miss, terlihat peningkatan performa yang sangat besar
  • Waktu build proyek besar seperti compiler Zig sendiri juga dipangkas dari 75 detik menjadi 20 detik
• Ke depannya, direncanakan implementasi paralelisasi penuh code generation, penguatan fitur linking, dan pengembangan backend aarch64
  • Pekerjaan aarch64 juga diperkirakan akan dipercepat dengan diperkenalkannya pass Legalize yang baru
• Perubahan terbaru bisa langsung dicoba melalui build terbaru dari branch master Zig

6 Juni 2025 – video pengenalan sistem build

• Video panduan YouTube untuk pemula sistem build Zig telah dirilis
  • Menjelaskan cara membuat modul dan paket Zig, serta cara mengimpornya ke proyek lain
  • Video tambahan terkait sistem build juga akan terus ditambahkan sebagai seri

20 Mei 2025 – penguatan dukungan target FreeBSD dan NetBSD

• Dengan digabungkannya Pull Request #23835 dan #23913, kini target FreeBSD 14.0.0+ dan NetBSD 10.1+ dapat membangun binary melalui zig cc dan zig build
  • Strategi ekstraksi informasi libc dan library terkait yang sebelumnya diterapkan pada glibc kini diperluas ke keluarga BSD
  • File abilists yang dihasilkan didistribusikan bersama Zig, sehingga saat cross-compilation dapat dibuat stub library yang cocok secara tepat dengan tiap library libc
  • Header sistem dan libc juga ikut disediakan berdasarkan versi OS terbaru
  • OpenBSD, Dragonfly BSD, SerenityOS, Android, dan Fuchsia juga menjadi target dukungan

9 April 2025 – situs resmi Zig dibangun sebagai Zine standalone

• Situs web resmi Zig kini diubah menjadi struktur yang dibangun sebagai Zine standalone
  • Berkembang dari skrip build lama menjadi executable tunggal
  • Disebut sebagai waktu yang tepat untuk mencobanya langsung

Kabar rilis dan peningkatan fitur

• Rilis 0.14.0 akan segera didistribusikan, dan sejumlah peningkatan penting sudah diterapkan
• Berkat peningkatan C interop dan runtime UBSan (Undefined Behavior Sanitizer), error SIGILL yang sebelumnya ambigu kini digantikan oleh pesan kesalahan yang lebih spesifik dan berguna
  • Contoh: lokasi dan penyebab signed integer overflow ditampilkan dengan jelas sehingga efisiensi debugging meningkat tajam
• Batasan UBSan yang masih tersisa:
  • Belum mendukung pemeriksaan dynamic type dan lifecycle terkait vptr pada C++
  • Penandaan lokasi yang akurat untuk atribut seperti assume_aligned, __nonnull, dan lainnya belum sepenuhnya selesai

7 Februari 2025 – inovasi debug allocator dan SmpAllocator

• Debug allocator didesain ulang untuk mendukung pengenalan ukuran halaman saat runtime serta berbagai optimalisasi
  • Mengurangi pembuatan memory map, menghapus pengulangan memset 0xaa/0x00 yang tidak perlu, serta menghilangkan struktur data pencarian dan trip
  • Metadata disimpan secara inline di dalam halaman untuk mempermudah implementasi error/verifikasi kompilasi
  • Dibanding malloc berbasis C yang lama, solusi ini unggul dalam keterbacaan dan kemudahan perawatan
• Dengan pengembangan SmpAllocator yang dioptimalkan untuk lingkungan konkuren, efisiensi eksekusi alokasi memori di lingkungan multi-thread dimaksimalkan
  • Benchmark perbandingan performa dengan glibc membuktikan secara nyata kecepatan dan efektivitas penggunaan sumber daya
  • Hasilnya dinilai sebagai titik balik penting yang membuat kegunaan Zig melampaui C dan libc

24 Januari 2025 – penyediaan lingkungan debugging khusus Zig

• Jacob mengembangkan fork LLDB (debugger) untuk Zig, memperkuat dukungan debugging bagi backend internal
  • Cara build dan penggunaan fork LLDB tersebut disediakan dalam dokumen wiki
  • Pengembang yang memakai backend internal Zig dapat memanfaatkan lingkungan debugging yang lebih canggih dengan alat ini

Kesimpulan

• Zig terus mendorong perubahan inovatif dengan target utama peningkatan performa, efisiensi build, dan kemudahan debugging berbasis teknologi internalnya sendiri
• Zig sedang membangun daya saing yang terdiferensiasi di seluruh algoritme independen, compiler, serta alat build/runtime
• Termasuk dukungan lintas platform seperti BSD, peningkatan pesan yang berpusat pada pengguna, dan inovasi model memori, Zig terus menghadirkan perkembangan yang benar-benar bermanfaat bagi praktisi rekayasa perangkat lunak

[GN⁺]

Komentar Hacker News

• Setahu saya, Zig sedang mengerjakan berbagai fitur setiap hari untuk membuat pengalaman pengembang menjadi lebih baik. Misalnya, baru-baru ini juga ada PR ini. Dulu hot code swapping juga sempat ada dalam rencana pengembangan Zig, dan dengan kecepatan pengembangan seperti ini, saya rasa fitur itu mungkin akan tersedia di x86_64 dalam waktu sekitar satu tahun. Secara pribadi, ketidaknyamanan terbesar yang saya rasakan adalah kecepatan comptime. Saya pernah bereksperimen menjalankan DSL brainF** saat waktu kompilasi, dan hasilnya benar-benar lambat (meski eksperimennya menyenangkan). Saya penasaran kapan bagian compiler ini akan ditingkatkan. Saya juga sangat menantikan backend-backend baru, dan ingin sekali mencoba membuat backend URCL saya sendiri untuk Zig 😉

  • Untuk peningkatan performa comptime, mereka sebenarnya sudah tahu apa yang perlu dilakukan, dan bahkan pernah memulai branch terkait sejak lama. Namun ini adalah bagian yang membutuhkan pengerjaan ulang kode analisis semantik dalam skala yang berarti, jadi meski ini salah satu pekerjaan penting, tetap harus bersaing dengan prioritas-prioritas lain

  • Hot code swapping adalah fitur yang bisa membawa perubahan besar di bidang pengembangan game. Mengejutkan bahwa di Zig ini nantinya direncanakan bisa didukung hanya lewat flag compiler. Dengan clang, hal seperti itu bahkan sulit untuk dicoba

  • Saya belum mendalami URCL, tapi ini malah membawa saya ke lubang kelinci yang lain. Saya jadi membayangkan skenario yang benar-benar aneh, di mana IR yang dibuat untuk Minecraft menjadi target kompilasi nyata sebuah bahasa

  • Saya penasaran apakah membuat backend kustom itu mudah. Saya belum pernah mencobanya sendiri, tetapi saya tertarik bereksperimen dengan backend yang menerima AIR lalu membuat laporan keamanan memori (misalnya memeriksa penggunaan nilai yang tidak terdefinisi, stack pointer escape, use-after-free, double free, alias xor mut, dan sebagainya)

  • Saya penasaran apakah comptime yang benar-benar lambat memang masalahnya. Saya sedang membuat library JSON-RPC, dan pada waktu kompilasi saya banyak memanfaatkan comptime untuk mendistribusikan JSON ke fungsi arbitrer. Karena dengan sistem tipe statis Zig yang kuat, mustahil melakukan dispatch dinamis ke fungsi dengan parameter arbitrer saat runtime, saya terpaksa membuat pemetaan tipe fungsi pada waktu kompilasi. Kekhawatirannya adalah ukuran biner pasti membesar karena kode yang sudah di-comptime akan tersalin untuk setiap fungsi

• Mencapai titik ini saja sudah pencapaian yang luar biasa. Seperti yang disampaikan di devlog, yang akan datang malah lebih menarik. Gagasan bahwa compiler hanya mengubah bagian biner yang diperlukan saat build terasa segar dan radikal, dan berkat proyek Zig kini itu menjadi tujuan yang realistis. Masa ke depan akan sangat menarik

• Disebutkan bahwa pada proyek besar seperti compiler Zig, waktu build turun dari 75 detik menjadi 20 detik.
  Saya sangat penasaran sampai sejauh mana ini masih bisa ditingkatkan. Pengembang Zig terasa sangat pintar.
  Saya juga penasaran seperti apa package management-nya. Dulu saya sempat ingin mencoba aplikasi QuickJS + SDL3 dengan Zig, tetapi karena kerumitan C++ akhirnya saya beralih ke Rust. Saya ingin mencobanya lagi di Zig

  • Package management Zig lebih manual dibanding Rust. Dari CLI kita mengambil URL paket secara langsung, lalu mengimpor modulnya di skrip build. Keuntungan pendekatan ini adalah bahkan arsip arbitrer pun bisa dengan mudah dipakai sebagai dependensi, dan banyak paket library C untuk Zig memang hanya menghubungkan rilis untampered (tarball) langsung dari skrip build. Namun, untuk pemula ini bisa sedikit rumit
    Untuk SDL3, ada wrapper Zig native (https://github.com/Gota7/zig-sdl3) dan juga https://github.com/castholm/SDL yang lebih sederhana, yaitu membuat library/API C terasa lebih seperti Zig
    QuickJS hanya mendukung C API (https://github.com/allyourcodebase/quickjs-ng)
    Zig sangat memudahkan penggunaan paket C secara langsung, tetapi karena tipenya ketat, saat menangani API kita mungkin akan sering perlu type casting

  • Compiler D dmd bisa mengompilasi dirinya sendiri dalam sekitar 18,4 detik untuk build debug.
    Prosesor saya adalah AMD Athlon 64 X2 (4400+) yang sangat tua, tetapi tetap begitu cepat sampai saya belum pernah merasa perlu upgrade
    (termasuk daftar detail informasi CPU)

  • Saya penasaran apakah ada panduan untuk membangun Zig dalam 20 detik demi siklus pengembangan yang cepat. Dulu ketika membangun Zig, ada beberapa stage—terutama bootstrap di WASM—yang membuatnya sangat lama

  • Sangat mengejutkan bahwa Zig bisa mengompilasi dirinya sendiri dalam 75 detik bahkan saat masih menggunakan LLVM

• Saya sama sekali tidak berniat menuntut hal yang berlebihan dari Zig, dan saya paham ini open source, tetapi yang paling saya minati adalah jadwal rilis 1.0 yang realistis.
  Zig adalah bahasa yang hampir sepenuhnya mewujudkan apa yang saya inginkan dari bahasa tingkat rendah, dan sekarang saya hanya menunggu stabilisasinya.
  Dan saya sungguh mengagumi filosofi desain minimalis Zig

  • Setahu saya, proyek nyata seperti tigerbeetle biasanya mengunci ke versi rilis tertentu dan hanya memakai nightly untuk eksperimen

• Sebagai pemula total, saya penasaran apa keunggulan Zig dibanding bahasa lain. Saya memahaminya sebagai C yang lebih modern, tetapi saya ingin tahu bagian mana yang membuatnya “modern”

  • Beberapa kelebihan yang langsung terlintas
    • sistem build terintegrasi sehingga tidak perlu menggabungkan banyak alat dan bahasa terpisah
    • menyediakan slice yang panjangnya diketahui secara jelas, alih-alih array C (dengan masalah buffer overflow)
    • tipe optional yang jelas, dengan null pointer yang tidak diizinkan secara default (dan akan tampak eksplisit di tipe bila memang diperlukan)
    • enum, tagged union, dan pemaksaan pengecekan exhaustive pada statement switch
    • penanganan error yang jelas (agak bergaya Rust). Jika sebuah fungsi bisa mengembalikan error, pemanggil tidak bisa mengabaikannya. Bukan seperti C yang membiarkan nilai balik diabaikan begitu saja. Meski begitu, sayangnya belum ada sintaks standar untuk mengembalikan error dan data sekaligus
    • blok defer, errdefer untuk menjalankan pembersihan otomatis saat fungsi selesai atau saat terjadi error
    • pembuatan kode dengan comptime dan refleksi tipe (@typeInfo dsb.) sebagai pengganti makro
    • allocator memori dikelola langsung oleh pemanggil (memberi lebih banyak kendali atas lokasi dan cara alokasi memori)
    • jika memakai GeneralPurposeAllocator, setidaknya bagi pemula, pelacakan kebocoran memori jadi lebih mudah
      Saya tidak terlalu akrab dengan C, dan karena banyak hal di C yang terasa tidak masuk akal dan tidak intuitif, saya selalu merasa ada hambatan untuk masuk ke pemrograman tingkat rendah. Zig adalah bahasa pertama yang membuat saya merasa pemrograman sistem itu menyenangkan dan menarik

• Saya penasaran apakah ada panduan untuk build Zig dalam 20 detik. Saya ingin mempercepat siklus pengembangan, tetapi dulu membangun stage1/2/3 semuanya memakan waktu lama sehingga sulit untuk berkontribusi

• Jika membangun hello world dari zig init di Zig menghasilkan 9,3MB, maka dengan flag -Doptimize=ReleaseSmall ukurannya turun menjadi 7,6KB
  Hanya dengan satu flag, perbedaannya bisa lebih dari 1000 kali lipat

  • Sebenarnya 82% dari perbedaan itu berasal dari informasi debug
    -OReleaseSmall -fno-strip menghasilkan 580KB, sedangkan -ODebug -fstrip bisa turun menjadi 1,4MB
    Dengan backend x86 Zig, pengalaman debugging juga jauh lebih baik lewat fork LLDB khusus Zig
    Saya tidak terlalu ingat apakah logika comptime saat ini sudah bisa dilihat langkah demi langkah saat debugging, tetapi itu sempat menjadi topik diskusi baru-baru ini

• Saya merasa Julia mungkin layak mempertimbangkan Zig sebagai compiler demi mendapatkan keuntungan performa. Saya juga ingat bagaimana para pengembang Julia selalu cemas akan regresi performa setiap kali ada rilis

  • Julia pada dasarnya sangat terikat dengan LLVM. Banyak bagian ekosistemnya bergantung pada keberadaan LLVM intrinsics, autodiff (Enzyme), kompilasi GPU, dan sebagainya.
    Compilernya sendiri sedang dibuat agar makin retargetable, dan area ini juga sedang aktif diteliti.
    Di masa depan, masih mungkin dibayangkan Zig menjadi compiler alternatif untuk sebagian dari bahasa tersebut

  • Ada pendapat bahwa LLVM sendiri pada praktiknya adalah public API Julia. Memang ada makro seperti @code_llvm yang langsung menampilkan IR

  • Ini jelas akan membantu mengurangi waktu kompilasi, tetapi di sisi Julia sendiri juga masih banyak pekerjaan yang bisa dilakukan
    Misalnya memperinci cache kompilasi, tooling untuk mencegah invalidation, menghapus optimisasi world splitting, meningkatkan pemanfaatan multithreading di compiler, precompilation otomatis untuk signature tertentu, serta fitur untuk mengompilasi/menukar kode secara lazy dan hot-swap

• Ini kemajuan besar bagi Zig, dan menurut saya akan menjadi pembeda utama ke depan dibanding Rust. Sebagai catatan, saya sendiri yang menulis sebagian besar kode rendering untuk alat analisis performa tersebut, dan saya senang kode saya dipakai luas secara online
  tautan proyek poop

  • Rust juga punya upaya serupa yang memanfaatkan cranelift
    Lihat rustc_codegen_cranelift

• Saya rasa ini memang salah satu prasyarat untuk menghadirkan kembali fitur async/await di Zig
  FAQ resmi Zig tentang async juga layak dilihat

  • Bagian ini sebenarnya sudah dibereskan, dan dalam 2–3 bulan ke depan kemungkinan akan ada pembaruan yang menarik. Mereka hampir seperti membuat ulang seluruh I/O, seolah-olah sedang menulis ulang standard library

  • Menurut tautan itu, async tampaknya bisa saja tidak kembali sama sekali, atau setidaknya masih mustahil sebelum 2028