Zig: Memindahkan semua fitur manajemen paket dari compiler ke sistem build

• Sejalan dengan alur yang memisahkan build.zig dan sistem build ke proses terpisah, Zig memindahkan logika manajemen paket ke proses maker di luar executable compiler
• Dengan berpindahnya zig build, zig fetch, zig init, dan zig libc ke sisi maker, kode untuk pemrosesan HTTP, TLS, Git, kompresi, dan build.zig.zon didistribusikan dalam bentuk source
• Dalam struktur ini, fitur manajemen paket dapat diperbaiki tanpa membangun ulang compiler, dan karena maker dikompilasi dengan ReleaseSafe, pemeriksaan keamanan untuk pekerjaan networking juga diaktifkan
• Tujuan awalnya adalah mengekspos build server protocol untuk menyelesaikan masalah perubahan --build-runner yang menghambat ZLS; dalam pohon proses baru, maker tetap menjadi induk configurer sehingga eksekusi ulang konfigurasi dapat ditangani lebih stabil
• Dampak bagi pengguna tidak besar, tetapi ukuran executable Zig turun 4% dari 14,1MiB menjadi 13,5MiB, dan --maker-opt serta --zig-lib-dir masing-masing digantikan oleh variabel lingkungan ZIG_DEBUG_MAKER dan ZIG_LIB_DIR

---

Pemindahan logika manajemen paket

• Setelah script build.zig milik pengguna dan sistem build itu sendiri dipisahkan ke proses terpisah, Zig mengubah strukturnya agar logika manajemen paket juga berada di sisi sistem build
• Subcommand yang dipindahkan ke proses maker adalah sebagai berikut
  • zig build
  • zig fetch
  • zig init
  • zig libc

Kode yang dikeluarkan dari executable compiler

• Area kode besar yang sebelumnya berada di dalam executable compiler kini didistribusikan dalam bentuk source
  • Logika pengambilan paket
  • Klien HTTP dan networking
  • TLS dan kriptografi terkait
  • Protokol Git
  • xz, gzip, zstd, flate, zip
  • Parsing, validasi, dan pemrosesan lain untuk file build.zig.zon
• Fitur-fitur ini dapat dipatch tanpa membangun ulang compiler, sehingga pengguna dan kontributor dapat bereksperimen dengan lebih mudah
• Karena executable maker dikompilasi dalam mode ReleaseSafe, pemeriksaan keamanan diaktifkan untuk pekerjaan networking dalam manajemen paket
• Kode kriptografi yang digunakan untuk networking dan hashing file dapat memanfaatkan instruksi CPU khusus yang tersedia di host

Struktur proses dan build server

• Motivasi awalnya adalah mengekspos build server protocol untuk mengatasi masalah yang menghambat ZLS
• Dalam struktur sebelumnya, zig build menangani compiler dan package manager sekaligus, sementara builder di bawahnya berisi logika build.zig pengguna dan implementasi sistem build
• Setelah pemisahan maker/configurer, strukturnya adalah sebagai berikut
  • zig build: compiler + package manager
  • configurer: logika build.zig pengguna
  • maker: sistem build
• Dalam struktur ini, zig build --watch yang berjalan lama harus mengeksekusi ulang configurer ketika mendeteksi perubahan pada build.zig atau file terkait; untuk itu, maker harus berhenti agar zig build mendapat kesempatan menjalankan ulang logika manajemen paket
• Dalam struktur baru, zig build hanya menangani compiler, sedangkan maker di bawahnya menangani sistem build dan package manager, dan configurer menjadi proses anak dari maker
• Saat konfigurasi perlu dijalankan ulang, maker tetap dapat hidup sebagai proses induk
• Pada build server yang direncanakan, alih-alih klien menyambung kembali setelah server berhenti, struktur yang memberi tahu klien tentang perubahan konfigurasi menjadi memungkinkan

Perubahan yang dapat diamati

• Sebagian besar bukan perubahan yang memutus kompatibilitas, tetapi ada perbedaan yang dapat dilihat pengguna
  • Ukuran binary executable Zig: berdasarkan ReleaseSmall tanpa LLVM, turun dari 14,1MiB menjadi 13,5MiB, berkurang 4%
  • Flag --maker-opt digantikan oleh variabel lingkungan ZIG_DEBUG_MAKER
  • Flag --zig-lib-dir digantikan oleh variabel lingkungan ZIG_LIB_DIR

Isu pemblokir yang tersisa sebelum Zig 0.17.0

• Setelah rangkaian perubahan ini, isu pemblokir utama yang tersisa menjadi pekerjaan inti sebelum tag Zig 0.17.0
  • MVP build server protocol: diperlukan untuk menghapus hambatan bagi ZLS
  • Memperkenalkan konsep penambahan path dependency untuk build script itu sendiri
  • Membuat zig build --watch mendeteksi perubahan build script dan menjalankan ulang dirinya sendiri
  • Cache miss build script akibat cwd yang berbeda
• Karena pada Juli ada dua konferensi dan persiapan presentasi, penyelesaian pekerjaan-pekerjaan ini secara realistis diperkirakan akan jatuh pada awal Agustus
• Techatrix dari tim ZLS telah menghubungi dan berkolaborasi dalam pengerjaan build server protocol, dan sedang mencari sponsor

[GN⁺]

Komentar Hacker News

• Pengembang Zig, Go, dan Python kadang mengumumkan bahwa mereka mengeluarkan cairan pendingin dari tangki bahan bakar, lalu para pendukung bersorak karena itu bagus untuk bahasa tersebut dan akan sangat meningkatkan performa
  Tapi yang lebih membuat penasaran adalah kenapa sejak awal cairan pendingin dimasukkan ke tangki bahan bakar

  • Pada tahap awal proyek seperti ini, kenyamanan pengembang individu sering lebih diprioritaskan daripada memikirkan secara mendalam konsekuensi desainnya
    Memasukkan manajemen paket ke dalam compiler memang nyaman, tetapi ketika bahasa dan tool mulai dipakai luas, fitur yang tadinya menguntungkan individu berubah menjadi utang teknis yang menghambat adopsi
    Di banyak proyek, pengembang memilih cara yang nyaman untuk menghindari “pekerjaan sulit yang sebenarnya perlu dilakukan”, dan karena orang lain juga tidak ingin melakukan pekerjaan sulit itu, akhirnya hal tersebut menjadi kebiasaan
  • Ada juga logika yang bisa membenarkan hal ini
    Jika mengimplementasikan package manager di dalam build system tetapi juga ingin mempertahankannya di compiler, pertama-tama harus diputuskan abstraksi seperti apa yang akan diletakkan di antara compiler dan build system
    Ini juga memengaruhi sistem import dan bagian-bagian fundamental bahasa, dan hal-hal seperti ini harus dirancang dengan benar serta sulit diubah belakangan
    Awalnya, menggabungkan manajemen paket dan compiler dengan kuat lalu merancang mundur dari pengalaman pemrograman yang diinginkan bisa membuat dampaknya ke pengguna lebih kecil saat implementasinya diubah nanti
    Khususnya pada Python, sistem import menjadi sangat kompleks dan penuh kekurangan karena harus mengakomodasi manajemen paket yang dilakukan dengan berbagai cara
    Sebaliknya, Go sejak awal dirancang dengan mempertimbangkan manajemen paket, jadi sintaks terkait import relatif kecil dan rapi. Tentu saja, itu bukan berarti saya setuju dengan semua keputusan desainnya
  • Kedengarannya seperti itu karena Anda belum pernah benar-benar membuat sesuatu
    Bahkan untuk produk kecil pun sulit memprediksi bagaimana tiap komponen akan saling berinteraksi, jadi terus-menerus perlu diperbaiki
    Sekarang bayangkan Anda sedang membuat bahasa pengganti C yang self-hosting
  • Saya merasakan hal yang persis sama soal performa. Ini tidak ada hubungannya dengan bahasa pemrograman tertentu maupun optimisasi saya sendiri
    Semakin besar peningkatan kecepatannya, semakin heboh soraknya, tetapi sebagian besar optimisasi bukan teknik cerdas melainkan menemukan lewat profiler bahwa “eh, cairan pendingin seharusnya tidak masuk ke tangki bahan bakar”
    Sebagian besar bottleneck performa bukanlah batasan hakiki dari hardware atau dari masalah itu sendiri
    Memang ada jumlah kerja minimum yang diperlukan untuk mendapatkan hasil, tetapi alasan aplikasi lambat hampir selalu karena berbagai tetek bengek tambahan yang ditumpuk di atasnya
  • Saya tidak terlalu paham Zig atau Python jadi sulit menilai, tetapi di Go saya sama sekali tidak pernah merasa seperti itu. Saya juga tidak tahu kapan hal seperti itu pernah terjadi

• Pengembangan Zig terasa benar-benar memiliki suasana yang sehat

  • Melihat Zig belakangan ini membuktikan bahwa craft pengembangan software belum mati atau digantikan oleh LLM
    Saya mengakui bahwa saya memakai LLM setiap hari dan mereka bekerja sangat baik untuk berbagai jenis masalah, kadang sampai mengejutkan, tetapi saya tidak ingin bahasa pemrograman yang dibuat oleh LLM
    Setiap baris kode, keputusan, dan trade-off dalam bahasa pemrograman itu penting
    Bahasa yang dirancang dan dikodekan hanya berdasarkan vibe akan menjadi bencana
    Belum ada model yang pernah menunjukkan kode yang cukup meyakinkan untuk menyimpulkan sebaliknya. Bahkan Fable, meskipun jelas lebih baik daripada model terbaik sebelumnya, tetap sama
    Model tidak memiliki keinginan, tidak punya pandangan yang bermakna, dan tidak tahu apa yang terasa nyaman atau tidak nyaman dalam sebuah bahasa. Hal yang sama berlaku pada antarmuka GUI atau CLI yang cukup kompleks
    Bahasa seperti Zig tidak mungkin muncul dari LLM kecuali hanya menyalin Zig, dan bahkan jika menyalin pun hasilnya akan menjadi versi yang lebih buruk
    Yang dimaksud menyalin dengan LLM di sini bukan cp source tree secara harfiah, tetapi semacam LLM menulis spesifikasi lalu LLM lain mengimplementasikan bahasa itu sesuai spesifikasi tersebut
  • Membuat sesuatu dengan Zig juga cukup menyenangkan
    Saya pernah membuat bootloader dan mengerjakan UEFI, dan secara pribadi itu terasa jauh lebih mudah dibanding saat melakukannya dengan C
    Meski begitu, saya juga cukup bias karena ada kesenangan tersendiri dalam mempelajari sesuatu yang baru dan mengilap

• Saya penasaran apakah perubahan ini adalah perubahan yang sama yang menyebabkan @cImport dihapus dari Zig dan dipindahkan ke build system
  Ini murni masalah pengalaman pengguna, dan saya paham bahwa pemisahan build system dan compiler itu penting bagi maintainer, tetapi tetap saja agak disayangkan bahwa stabilitas pengembangan didahulukan daripada pengalaman pengguna
  Ini memang keputusan yang benar, tetapi tetap terasa sedih, dan menurut saya @cImport adalah fitur pembeda yang sangat kuat dari bahasa ini

  • Tidak juga
    Perubahan ini berkaitan dengan kode untuk mengunduh dan mengekstrak paket pihak ketiga
    Perubahan @cImport adalah bagian dari upaya untuk suatu hari menjadikan ketergantungan Zig pada LLVM/libclang sebagai sesuatu yang opsional, dan nantinya bisa dipindahkan menjadi paket pihak ketiga, tetapi tampaknya tidak berhubungan langsung

• Saya pernah membaca di suatu tempat bahwa tujuan jangka panjangnya adalah memindahkan build system ke dalam VM WebAssembly
  Kalau begitu, itu luar biasa

  • Saya penasaran keuntungan apa yang diberikannya dalam proses build

• Ini perubahan yang bagus untuk Zig
  Keinginan saya untuk berpindah dari Go ke Zig cukup besar, tetapi untuk saat ini saya juga menikmati mengamatinya dari samping

  • Tergantung use case, keduanya bisa dipakai, dan mungkin memang seharusnya begitu

• Setiap kali sebuah bahasa membuat sistem paketnya sendiri, saya selalu merasa kita melewatkan sesuatu yang besar
  Satu-satunya pengecualian adalah C/C++, karena entah baik atau buruk memang belum ada yang cukup mapan di sana
  Pilihan seperti ini nanti bisa membuat prosedur yang sangat rumit ketika harus mencampur beberapa bahasa
  Sistem packaging memang mempermudah pekerjaan, tetapi begitu Anda harus memakai bahasa lain, proses setelahnya jadi lebih rumit

  • Saya penasaran menurut Anda kita melewatkan apa
    Apakah maksudnya Anda ingin satu build system untuk semua bahasa? Sistem seperti Bazel memang ada dan sering dipakai juga untuk proyek multi-bahasa, tetapi secara realistis tampaknya sudah terbukti bahwa build system yang punya pengetahuan khusus per bahasa jauh lebih mudah ditangani
  • Menurut saya justru bagus kalau C++ tidak punya sistem packaging yang distandardisasi
    Itu membuat orang berpikir lebih hati-hati sebelum menambahkan dependensi
    Dependensi seperti ini sering memiliki biaya tersembunyi seperti kerentanan keamanan
    Cukup banyak sistem penting ditulis dalam C++, jadi terlalu berisiko jika bergantung pada puluhan paket pihak ketiga yang mudah diakses tanpa mengaudit tiap paket dengan benar
  • C seharusnya sudah memperbaiki berbagai masalah dan menambahkan package manager, atau setidaknya secara resmi mengakui satu
    Zig sedang mengisi kekosongan itu
  • Dunia masih belum berhasil melakukan standardisasi pada build system lintas platform multi-bahasa yang bagus
    Secara praktis, build system seperti itu hanya Buck dan Bazel, dan keduanya membawa terlalu banyak beban dari organisasi besar di belakangnya
    Sangat disayangkan
  • Conan dan vcpkg sudah cukup mapan

• Pemisahan concern dilakukan dengan cara yang sangat masuk akal