Zig – Menambahkan implementasi std.Io untuk io_uring dan Grand Central Dispatch

 (ziglang.org)
2 poin oleh GN⁺ 2026-02-15 | 1 komentar | Bagikan ke WhatsApp
  • Implementasi berbasis io_uring dan Grand Central Dispatch (GCD) yang baru telah diintegrasikan ke modul std.Io.Evented di pustaka standar Zig
  • Kedua implementasi bekerja dengan metode peralihan stack di ruang pengguna (fibers, stackful coroutines, green threads)
  • Saat ini masih berada pada tahap eksperimental, dan memerlukan pekerjaan lanjutan seperti perbaikan penanganan error, penghapusan logging, analisis penyebab penurunan performa, serta penguatan pengujian
  • Pada kode aplikasi yang sama, cukup menukar backend I/O untuk beralih dengan mudah antara io_uring atau GCD
  • Kedua implementasi juga berjalan di kompiler Zig, dan setelah distabilkan berpotensi berkembang menjadi fondasi integrasi I/O asinkron lintas platform

Implementasi std.Io.Evented berbasis io_uring dan GCD

  • Menjelang akhir siklus rilis Zig 0.16.0, std.Io.Evented diperbarui agar mencerminkan perubahan API terbaru

    • Implementasi yang baru ditambahkan adalah io_uring (Linux) dan Grand Central Dispatch (GCD) (macOS)
    • Keduanya menggunakan teknik peralihan stack di ruang pengguna (fibers, stackful coroutines, green threads)

  • Kedua implementasi saat ini masih berstatus eksperimental, dan masih ada sejumlah tugas peningkatan agar dapat dipakai secara stabil

    • Perlu peningkatan penanganan error
    • Perlu penghapusan logging serta diagnosis penyebab penurunan performa (terjadi penurunan performa kompiler saat menggunakan IoMode.evented)
    • Beberapa fungsi belum diimplementasikan dan cakupan pengujian perlu diperluas
    • Perlu penambahan fungsi bawaan untuk memeriksa ukuran stack maksimum per fungsi (agar tetap praktis saat overcommit dinonaktifkan)

Contoh pergantian implementasi I/O

  • Pada kode aplikasi yang sama, sistem dapat berjalan hanya dengan menukar backend I/O

    • Dalam contoh kode, jika memakai std.Io.Evented alih-alih std.Io.Threaded, program akan berjalan dengan basis io_uring
    • Fungsi app tetap sama, dan hasil keluarannya (Hello, World!) juga sama

  • Perbedaan dua metode eksekusi dapat dilihat melalui perbandingan hasil strace

    • hello_threaded memakai pemanggilan I/O berbasis thread biasa
    • hello_evented menggunakan system call io_uring (io_uring_setup, io_uring_enter, dan lainnya)

Penerapan pada kompiler Zig dan status saat ini

  • Kompiler Zig sendiri juga berjalan normal dengan std.Io.Evented

    • Kompiler dapat dijalankan baik dengan io_uring maupun GCD
    • Namun, penyebab penurunan performa masih belum diketahui, sehingga perlu analisis tambahan

  • Perubahan ini membuat kode Zig semakin mendekati struktur yang memungkinkan pergantian implementasi I/O dengan mudah

    • Ini menjadi landasan untuk menangani model I/O asinkron per platform secara lebih terpadu

Tugas selanjutnya

  • Diperlukan peningkatan performa dan penguatan pengujian agar bisa digunakan secara stabil
  • Jika fitur pengelolaan ukuran stack ditambahkan, maka penggunaan praktis juga dimungkinkan di lingkungan dengan overcommit dinonaktifkan
  • Setelah matang, lapisan abstraksi I/O asinkron Zig diperkirakan akan menjadi lebih kuat

Kesimpulan

  • Pembaruan kali ini merupakan langkah maju penting dalam perluasan sistem I/O standar Zig
  • Dengan mengintegrasikan io_uring dan GCD, Zig menyiapkan fondasi untuk konsistensi pemrosesan asinkron lintas platform
  • Setelah proses stabilisasi selesai, peluang untuk mewujudkan model I/O Zig yang berkinerja tinggi dan fleksibel akan semakin besar

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-15
Komentar Hacker News

  • Saya bukan penggemar Zig, tetapi menyenangkan melihat tim kecil yang terus berkembang
    Sikap yang lebih mementingkan eksperimen dan perbaikan bertahap daripada sekadar penyelesaian terasa mengesankan
    Menurut saya, bergerak menuju tujuan jangka panjang lebih penting daripada terburu-buru merilis 1.0
    Untuk proyek yang sangat berpusat pada satu orang, ini pencapaian yang luar biasa, dan orang-orang yang bekerja keras pantas mendapat pengakuan

    • Setiap kali saya mempelajari bahasa baru, saya biasanya mencoba membuat game engine dengan server multiplayer TCP/UDP, dan baru-baru ini saya mencobanya dengan Zig
      Sejauh ini, itu adalah pengalaman paling menyenangkan dan produktif yang pernah saya rasakan
      Kesederhanaan Zig jauh lebih cocok bagi saya daripada manajemen memori Rust yang ketat
      Hidup itu singkat, dan saya hanya ingin membuat perangkat lunak yang cepat dan rapi

  • Setiap ada tulisan tentang Zig, kritiknya selalu banyak, tetapi saya tidak mengerti kenapa orang begitu peduli
    Semangat rekayasa Andrew dan tim dalam mewujudkan apa yang mereka yakini justru terasa menginspirasi
    Tidak perlu khawatir apakah Zig akan jadi arus utama; kalau membantu memecahkan masalah, itu sudah cukup
    Bahasa pemrograman tidak perlu diperlakukan seperti identitas

    • Untuk menghilangkan fenomena ini, insentif ekonomi yang diterima programmer harus diubah
      Bahasa dan library pada akhirnya adalah ‘keahlian yang bisa dijual’, jadi orang sadar akan nilai pasar dari alat yang mereka gunakan
      Selain itu, ada juga masalah bahwa para pengambil keputusan cenderung melihat engineer sebagai aset yang bisa diganti
    • Perdebatan bahasa seperti ini bukan cuma terjadi pada Zig
      Ini sudah berulang pada Lisp, Ruby, Rust, dan lainnya, dan pertarungan identitas adalah masalah kronis di industri
    • Stack bahasa baru menambah beban pemeliharaan pada distribusi Linux
      Dukungan keamanan, arsitektur, dan pengelolaan jangka panjang tetap dibutuhkan, tetapi developer sering mengabaikan biayanya
      Zig juga belum stabil, sehingga paket sering hanya bisa dikompilasi pada versi tertentu
      Saya juga ragu apakah masalah yang sebenarnya bisa diselesaikan dengan memperbaiki bahasa lain perlu dipaksa diselesaikan dengan bahasa baru
    • Untuk menjadi bahasa arus utama, dibutuhkan ekosistem library yang dapat diprediksi yang mencakup sebagian besar use case

  • Saya merasa tidak ada gunanya mengikuti Zig sebelum mencapai 1.0
    Struktur saat ini tampaknya masih sangat mungkin dirombak beberapa kali lagi
    Saya dulu juga tertarik, tetapi saya tidak yakin akan sempat melihat 1.0 dalam hidup saya

    • Faktanya, sebagian besar breaking change di Zig terjadi di standard library (stdlib)
      Fungsi dasar seperti file I/O hampir tetap sama, biasanya hanya namespace-nya yang berubah
      Saya pribadi merasa ‘bahasa yang hidup’ itu lebih baik
      Bahkan setelah 1.x nanti, saya berharap ada strategi pengelolaan antarmuka per versi agar stdlib tetap ramping
    • Saya suka bahasa Zig itu sendiri, tetapi mulai meragukan kualitas stdlib-nya
      Saat membuat framework I/O sendiri, saya menemukan kurangnya pengujian dan bahkan kode assembly yang salah
      Saya sudah beberapa kali menyorotinya, tetapi belum diperbaiki, jadi kepercayaan saya menurun
    • Untuk proyek berskala besar mungkin orang akan ragu, tetapi Zig sudah punya nilai bisnis
      Terutama di lingkungan cloud, optimasi performa bisa memangkas biaya server lebih dari 90%
      Python atau Node punya batasannya, jadi pada akhirnya kita harus turun ke C, C++, Rust, atau Zig
      Di antara itu, Zig mudah dipelajari, mudah dibaca, dan enak diuji
    • Sebagai referensi, Bun juga ditulis dengan Zig
      Ini sudah merupakan bahasa yang dipakai di tingkat produksi
    • Tim kami (ZML) terus mengikuti branch master Zig sejak adopsi std.Io
      Sebagian besar perubahan memang terasa sebagai peningkatan bahasa yang nyata

  • Menarik bahwa Zig lebih dulu mencoba implementasi io_uring ketika dukungan io_uring di Rust sendiri masih belum selesai
    Di Rust, sulit merancang abstraksi yang aman dan zero-cost

  • Kabar ini masih tentang implementasi yang belum selesai
    Misalnya, versi GCD belum memiliki networking
    Antarmukanya juga terus membesar, jadi ini lebih mirip snapshot saat ini daripada sesuatu yang benar-benar final

    • Tetapi di bagian awal tulisan sudah dijelaskan bahwa ini masih tahap eksperimental,
      dan ada daftar 6 tugas utama yang masih harus dikerjakan ke depan

  • Ada issue terkait optimasi memori stack
    Dibutuhkan fitur agar penggunaan [500]u8 di blok yang berbeda tetap hanya memakan 500 byte di stack frame
    Ini sangat penting terutama dalam kaitannya dengan stack coroutine green thread

  • Saya memandang positif upaya perbaikan berkelanjutan Zig
    Saat ini belum ada bahasa yang benar-benar menangani io_uring dengan baik
    Jika Zig bisa menyelesaikan bagian ini dengan baik, itu akan menjadi keunggulan besar
    Menurut saya, sikap yang lebih menghargai pembelajaran dan eksperimen daripada stabilitas justru lebih bernilai

    • Menarik juga bahwa orang menginginkan async bahkan di bahasa level rendah
      Saya sendiri lebih suka memakai libxev di Zig untuk mengendalikan io_uring secara langsung
    • Saya juga positif, tetapi saya penasaran kapan Zig akan merilis versi stabil jangka panjang (LTS) seperti C
      Salah satu faktor keberhasilan C adalah stabilitas dan budaya pengembangan yang konsisten

  • Saya suka bahwa Zig benar-benar serius menangani target freestanding
    Saya berharap versi 0.16 akan membuat penggunaan ulang kode menjadi lebih baik

  • Sudah lama saya tidak melihat bagian dalam macOS, dan menyenangkan melihat GCD masih dipertahankan
    Menurut saya ini pendekatan yang seimbang terhadap paralelisasi

  • Saat bahasa lain masih berdebat, Zig langsung mencoba, dan kalau perlu ya di-rollback
    Saya percaya API yang teruji di lapangan adalah desain terbaik
    Kita bisa tetap memakai versi lama, atau pindah ke versi terbaru untuk mendapatkan alat yang lebih bersih dan cepat

    • Jai berfokus pada pengembangan game, jadi kurang dalam hal generalitas maupun keamanan
      Ia rumit seperti C++, sementara Zig tetap mempertahankan kesederhanaan setingkat C
      Carbon juga masih belum benar-benar punya wujud
    • Mengkritik Zig karena belum 1.0 terasa aneh
      Jai sudah 11 tahun berada di closed beta, sedangkan Zig sudah dipakai di berbagai proyek nyata
    • Menurut saya lebih baik sebuah bahasa diselesaikan dengan benar, meski butuh 20 tahun
      Perubahan yang sembrono seperti yang terlihat pada Python 2→3, Rust async, Go generics, dan C++ justru lebih merugikan