Wawancara Mitchell Hashimoto: Ghostty, Zig, dan Pemeliharaan Open Source

 (alexalejandre.com)
10 poin oleh GN⁺ 5 jam lalu | 4 komentar | Bagikan ke WhatsApp
  • Mitchell Hashimoto, setelah Vagrant, Terraform, dan Vault, kini membuat Ghostty dan Vouch, sambil merangkum standar pribadinya tentang terminal, Zig, pemeliharaan open source, dan kualitas produk
  • Ghostty berawal sebagai proyek pribadi untuk mempelajari pemrograman GPU, pemrograman sistem desktop/node tunggal, dan Zig, lalu berkembang dengan tujuan menjadi terminal native lintas platform yang cepat dan kaya fitur
  • Menurutnya, terminal seharusnya tidak menampung semua hal seperti browser, melainkan memaksimalkan komposabilitas aplikasi berbasis teks, otomasi, dan model keamanan yang jelas, sementara aliran byte PTY yang tidak terstruktur tetap menjadi batasan
  • Maintainer open source tidak memiliki kewajiban kepada pengguna, tetapi untuk membuat perangkat lunak yang baik, ia menilai banyak masalah harus diselesaikan sebagai satu fitur yang konsisten, bukan dengan menerima setiap permintaan apa adanya
  • Perubahan besar di Zig memang membebani downstream, tetapi juga meningkatkan kualitas API dan tooling kompilasi, dan AI dinilai bisa mengurangi kerja berulang dalam perubahan besar sehingga menurunkan beban kompatibilitas mundur

Mengapa Ghostty dimulai

  • Mitchell Hashimoto setelah membuat Vagrant, Packer, Consul, Terraform, Vault, Nomad, dan Waypoint, kini membuat Ghostty dan Vouch
  • Ghostty berangkat dari kesadaran bahwa selama sekitar 15 tahun membuat aplikasi CLI, ia belum benar-benar memahami bagaimana emulator terminal bekerja
  • Setelah meninggalkan Hashicorp, ada tiga area yang ingin ia sentuh lagi
    • Pemrograman GPU dalam konteks sebelum AI
    • Pemrograman sistem desktop/node tunggal yang berbeda dari sistem terdistribusi
    • Penggunaan Zig
  • Tujuan awalnya adalah menjalankan vim dan compiler, membuat Ghostty bisa membangun dirinya sendiri, lalu membuang proyek itu
  • Setelah melihat lebih jauh ekosistem terminal, ia menilai masih kurang alat yang cepat, kaya fitur, native, dan lintas platform
  • Setelah dibagikan kepada teman-teman di Discord, muncul pengguna yang memakainya setiap hari, dan Discord Ghostty awalnya hanyalah ruang obrolan grup teman yang diubah menjadi ruang khusus
  • Karena ia menilai pengenalan publik bisa memicu perhatian berlebihan, proyek ini lama dijalankan sebagai beta tertutup

Sejauh mana terminal perlu diperluas

  • Hashimoto menolak arah yang mendorong terminal menjadi platform aplikasi raksasa tanpa batas
  • Terminal memang bisa menampung akses video, mikrofon, hingga layout responsif seperti browser atau runtime Java lama, tetapi menurutnya browser, desktop, dan aplikasi grid monospace berbasis teks masing-masing punya keunggulan berbeda
  • Aplikasi berbasis teks cepat dibuat, mudah diinteraksikan, dan harus memiliki model keamanan yang jelas
  • Kekuatan aplikasi berbasis terminal ada pada komposabilitasnya
    • TUI mungkin kurang demikian, tetapi sebagian besar alat CLI punya mekanisme yang memungkinkan dipakai lebih dari stdin/stdout, hampir seperti fungsi
    • Filsafat UNIX “lakukan satu hal dengan baik” adalah bentuk ekstremnya
    • Neovim dan alat AI makin banyak menyediakan flag command line
  • Aplikasi terminal yang lebih baik akan menghasilkan otomasi dan kemampuan scripting yang lebih baik pula
  • Sinyal in-band PTY, yaitu aliran byte tidak terstruktur termasuk escape sequence, tetap menjadi masalah besar
  • Ekosistem Nushell mencoba memperbaikinya di lapisan terpisah, tetapi Hashimoto menilai perbaikan yang lebih mendasar tetap diperlukan
  • Banyak orang tidak menyukai ekosistem Microsoft, tetapi ia menilai PowerShell melakukan banyak hal dengan benar dari sisi data terstruktur

Gagasan API terminal non-legacy

  • Saat memikirkan API terminal baru, Hashimoto merujuk pada framework dari platform aplikasi besar seperti browser, Emacs, Apple, Microsoft, Android, dan konsol game
  • Ia menilai perlu lebih dulu meneliti preseden yang sudah terakumulasi seperti DOM dan JS API di web, AppKit, Cocoa, SwiftUI milik Apple, Win32 dan WinUI di Windows, serta GTK dan Qt di Linux
  • Bahkan untuk akses clipboard, protokol terminal historis berfokus pada teks, sementara desktop sudah lama menangani gambar dan berbagai tipe MIME, sehingga dokumentasi clipboard tiap platform perlu dilihat
  • Ghostty belum memperkenalkan protokol kustom saat ini

  • API n-screen

    • Terminal saat ini umumnya memiliki dua layar: main screen dan alt screen
    • Main screen lebih dekat ke shell dan scrollback, sedangkan alternate screen lebih dekat ke Neovim dan sebagian besar TUI
    • Struktur ini bekerja dengan menyalakan atau mematikan salah satu mode, biasanya mengambil seluruh layar dan kehilangan scrollback
    • Hashimoto membayangkan API n-screen yang memungkinkan pembuatan dan pengisian layar tanpa batas di latar belakang
    • Tiap layar bisa punya ukuran grid berbeda dan bisa dioverlay, sementara emulator terminal menangani line wrap, selection, dan routing event mouse
    • Jika layar tertentu ditandai sebagai jendela independen, emulator terminal bahkan bisa merender di luar grid
    • Sebagai contoh, ia menyebut bentuk yang memungkinkan tab Neovim dibuka bersamaan seperti tab jendela native

  • Protokol tombol

    • Protokol mouse saat ini hanya bisa menerima event ketika pengguna mengklik sel grid di layar aktif saat itu
    • Item histori yang sudah masuk ke scrollback tidak bisa menerima event klik
    • Terminal saat ini mendukung protokol hyperlink OSC 8
    • Hashimoto membayangkan protokol tombol mirip OSC 8 yang saat diklik akan mengirim pesan yang sudah ditentukan program
    • Misalnya, tombol dengan ID open_profile bisa tetap terdaftar meski pengguna menggulir ke histori
    • Fitur ini berkaitan dengan aplikasi main screen yang memiliki scrollback, dan terhubung dengan masalah pada aplikasi main screen seperti Claude Code ketika membuka file atau tautan internal aplikasi tidak lagi berfungsi setelah masuk histori

Ketiadaan standar dan pemeliharaan open source

  • Hashimoto pernah bereksperimen mengganti seluruh protokol PTY dengan Wayland, tetapi membatalkannya
  • Ia melihat terminal bisa dipandang seperti server jendela yang mengelola jendela dan widget, dan Wayland merupakan protokol yang baik untuk menyelesaikan masalah desktop lokal dan rendering jendela
  • Salah satu masalah terminal adalah tidak ada lagi badan standardisasi
  • Spesifikasi lama masih ada, tetapi standardisasi selama 20 tahun terakhir pada praktiknya mengikuti apa yang dilakukan terminal paling populer
  • Akibatnya, berbagai fitur bercampur-aduk dan tidak ada pihak yang mendorong visi yang punya selera jelas
  • Ia belum menentukan jalur ke depan, dan menganggap mungkin juga untuk membuat ruang aplikasi berbasis teks yang sepenuhnya baru, lalu menambahkan lapisan terjemahan terminal untuk aplikasi legacy

  • Keseimbangan antara tuntutan pengguna dan visi besar

    • Hashimoto secara terbuka sudah lama mengatakan bahwa maintainer open source punya nol kewajiban kepada pengguna
    • Baris pertama lisensi open source adalah “as is, no warranty”, dan posisinya adalah pengguna menerima perangkat lunak gratis tanpa hak untuk menuntut
    • Namun pada saat yang sama, karena ingin membuat perangkat lunak yang baik, ia merasa tetap punya tanggung jawab untuk memperbaiki masalah dan membuat perangkat lunak menjadi lebih baik
    • Pada hari tertentu ia melihat issue dan memperbaiki masalah orang lain, sementara pada hari lain ia tidak melihat issue, diskusi, atau PR dan fokus pada hal yang ia inginkan sendiri
    • Jika setiap hari hanya menangani issue pengguna, perangkat lunak akan stabil tetapi mandek; jika semua PR diterima, perangkat lunak berubah tetapi kehilangan visi
    • Menurutnya, sebagian besar kontribusi hanya menyelesaikan masalah pribadi yang sangat spesifik, dan jika semuanya diterima maka kode akan menumpuk seperti gunung
    • Sebaliknya, bila masalah dipahami secara mendalam, banyak permintaan fitur bisa diselesaikan sekaligus dengan satu sistem yang elegan
    • Dalam video desain fitur, ia memberi contoh menutup 3-4 permintaan fitur terpisah dan menyelesaikannya sekaligus dengan satu fitur yang juga menjawab masalah lain

  • Membedakan kaya fitur dan gembung

    • Salah satu fitur yang paling sering diminta di Ghostty, yaitu pencarian, kini sudah diimplementasikan dan dirilis
    • Sebagian pengguna mengkritik bahwa pencarian merusak minimalisme Ghostty dan membuatnya gembung, tetapi Hashimoto menjawab bahwa Ghostty memang dipromosikan sebagai terminal kaya fitur
    • Ia membedakan antara kaya fitur dan bloat
    • Fitur pencarian memang memakai ruang disk dan pemuatan RAM, tetapi dirancang agar tidak menjalankan kode apa pun jika tidak digunakan
    • Karena itu, menurutnya fitur tersebut tidak menimbulkan biaya runtime bagi pengguna yang tidak memakainya
    • Ghostty ditujukan menjadi terminal yang bisa disesuaikan dengan kebutuhan pengguna, tetap bekerja dalam kondisi default, dan menyembunyikan fitur sampai benar-benar dibutuhkan atau dicari
    • Untuk permintaan mempertahankan flag penghapusan fitur, ia memandang bahwa maintainer mengelola flag itu dan pengguna memelihara fork yang menghapus fitur pada dasarnya adalah jenis tuntutan yang sama

Hak dalam open source, perubahan Zig, dan kualitas API

  • Hashimoto percaya seharusnya ada jauh lebih banyak fork pribadi maupun fork yang dirawat
  • Menurutnya, open source berbasis pendanaan venture telah melahirkan generasi yang mengharapkan proyek yang sangat polished dengan website, staf dukungan berbayar, serta dukungan Slack dan Discord
  • Padahal inti open source bukan jaminan produk, melainkan kebebasan dan hak
    • Menggunakan sesuka hati
    • Memodifikasi
    • Melakukan fork
  • Kestabilan atau kewajiban pemeliharaan tidak termasuk dalam hak-hak itu
  • Ia mengatakan commit yang memasukkan celah keamanan tidak bisa sepenuhnya disalahkan pada maintainer; pengguna juga bertanggung jawab karena tidak meninjau commit tersebut
  • Jika menginginkan jaminan yang lebih kuat dan hak untuk menyalahkan seseorang, maka pengguna harus membayar perangkat lunak itu dan membentuk hubungan vendor-pelanggan
  • Dalam proyek pribadi, ia bahkan bisa memilih tidak menggabungkan PR yang memperbaiki bug yang tidak ia alami sendiri
    • Karena merge berarti janji untuk memelihara kode itu selamanya

  • Sikap terhadap Zig

    • Saat memilih Zig, Hashimoto tahu apa yang ia hadapi, dan melalui patch compiler ia jadi memahami komunitas, budaya, dan filsafatnya
    • Perubahan I/O yang bahkan belum dimulai diperkirakan akan menjadi salah satu pekerjaan paling sulit di Zig
    • Popularitas Zig terus naik, tetapi Andrew tidak mundur dari perubahan yang ia anggap perlu, dan sebagai pengguna downstream Hashimoto justru menghargai hal itu
    • Zig 0.15 mengubah antarmuka writer dan memengaruhi hampir semua kode yang menghasilkan output, tetapi ia menilai API-nya sendiri menjadi jauh lebih baik
    • Zig berfokus pada tooling kompilasi, dan bahkan pernah menghapus fitur bahasa demi meningkatkan kecepatan kompilasi
    • Seluruh terminal lib-ghostty bisa dibangun seketika, tetapi menurutnya Andrew tetap menganggap waktu dalam hitungan milidetik itu terlalu lambat
    • Zig 1.0 pada akhirnya akan tercapai, tetapi menurutnya masih beberapa tahun lagi
    • AI bisa mengurangi penderitaan downstream akibat perubahan bahasa
    • Ketika berbagai konteks perubahan diperlihatkan lalu sisanya diminta diterapkan, sekitar 90% dari diff besar dapat ditangani secara otomatis
    • Jika cara berpindah dari keadaan A ke keadaan B bisa dijelaskan, itu menurutnya mengisyaratkan masa depan di mana makna kompatibilitas mundur menjadi berkurang
    • Ironisnya, meski Zig punya kebijakan anti-AI yang kuat, ia tetap menilai AI bisa meredam rasa sakit yang diberikan perubahan kepada pengguna downstream

  • Library dan desain API

    • Cara paling konkret untuk merancang library yang baik adalah dengan benar-benar memakai banyak library dari banyak komunitas
    • Seperti mempelajari bahasa pemrograman yang tidak akan dipakai dalam pekerjaan nyata, menggunakan library dari berbagai ekosistem memperluas sudut pandang
    • Saat kuliah, ia membuat produk mainan dengan Prolog, Haskell, Clojure, dan Java, sambil mempelajari build system, usability, library, web framework, web server, dan app server dari masing-masing ekosistem
    • Menurutnya, budaya tiap ekosistem meresap ke pemisahan concern pada library dan framework serta ke bentuk API-nya
    • Ia memberi contoh mencoba builder pattern yang lama dipakai di Java ke Ruby dan merasa hasilnya bagus sebagai bentuk transplantasi konsep
    • Menurutnya Docker melihat banyak elemen deployment dan runtime bercampur ke alur pengembangan, sedangkan Vagrant secara sengaja memakai noun, CLI, dan konfigurasi yang langsung berfokus pada pengembangan

  • Dilema pembuat alat dan tech stack

    • Hashimoto mengatakan dirinya sepanjang hidup adalah pembuat alat dan ia percaya pada dilema pembuat alat
    • Seseorang bisa memahami suatu masalah dengan sangat mendalam lalu membuat alat ideal, tetapi ketika alat itu menjadi populer, ia berisiko berubah menjadi pembuat alat yang kehilangan kontak dengan pengguna nyata
    • Ia sendiri memakai terminal setiap hari, tetapi tidak cukup banyak mengembangkan TUI, dan bergantung pada maintainer seperti rockorager yang memelihara banyak klien email dan IRC serta menulis spesifikasi
    • Soal tech stack saat ini, sikapnya kira-kira hanya “lumayan”
    • Ia melihat banyak hal baik di frontend, TypeScript, dan komunitas tipe React, tetapi menganggap perubahannya terlalu banyak, kompleksitasnya tinggi, dan lapisan abstraksinya tidak jelas
    • Ia mengatakan kompleksitas di banyak area meningkat secara nonlinier, seperti transisi dari HTTP/1 ke HTTP/2 dan HTTP/3
    • Menurutnya, industri bergerak terlalu cepat dan membuat hal-hal yang seharusnya bisa lebih sederhana menjadi rumit, dan AI beserta alat-alat terkait mempercepatnya

Prinsip, budaya, kualitas, dan pembelajaran

  • Ia mengatakan dokumen prinsip Hashicorp maupun cara pengembangan Ghostty semuanya merupakan cerminan dirinya sendiri, sehingga mudah dipraktikkan setiap hari
  • Menurutnya, jika menetapkan prinsip yang berbeda dari diri sendiri, akan sulit diwujudkan dalam tindakan nyata seperti resolusi tahun baru
  • Ghostty menaruh perhatian besar pada core lintas platform dan GUI native sekaligus
    • Core bersifat lintas platform
    • GUI tidak memaksakan lintas platform dan lebih memilih pendekatan native tiap platform
  • Ia memandang proyek open source dan internet seharusnya menjadi kumpulan suku-suku yang berbeda
  • Ia tidak suka jika bahasa pemrograman berubah menjadi semacam common denominator yang memuat semua fitur yang diinginkan semua orang, dan mengatakan bahwa batasan melahirkan kreativitas dan budaya
  • Ia mengatakan menyukai bahasa dan filsafat Rust, tetapi tidak menyukai budaya Rust, sambil menegaskan bahwa itu bukan berarti orang-orang di komunitas Rust itu buruk
  • Zig, menurutnya, punya posisi yang jelas dan terpolarisasi dalam hal teknologi, pengelolaan komunitas, pendanaan, PR, tulisan blog, hingga cara berbicara, dan ia menghormati keanehan itu sehingga terus memberi dukungan finansial dan tetap menggunakannya
  • Untuk merilis dengan cepat namun tetap berkualitas, perlu memahami bukan hanya masalah pelanggan tertentu, tetapi juga konteks yang membawa pengguna ke masalah itu serta masalah upstream-nya
  • Ia tidak tahu bagaimana menyelesaikannya dalam skala perusahaan, tetapi secara pribadi ia menilai dari sudut pandang bahwa dirinya sendiri adalah pengguna besar dari perangkat lunak yang ia buat
  • AI boleh dipakai secara kasar untuk demo atau memeriksa arah, tetapi kode yang dirilis harus dibaca, dipahami, lalu dikirim dengan kualitas yang baik
  • Dalam mempelajari C, yang lebih penting daripada bahasanya sendiri adalah memahami bagaimana komputer bekerja
    • Perlu memahami penjadwalan CPU, memori, hierarki cache, file system, serta disk dan akses file
    • Jika bekerja tepat di atas lapisan syscall seperti dengan C, Zig, atau Rust, lebih mudah memahami apa yang sedang terjadi
    • API membuka file di Python, JavaScript, dan Ruby mengabstraksikan banyak detail
    • Ia menyarankan agar bahkan fungsi standard library pun tidak diterima begitu saja; karena itu juga kode yang ditulis seseorang, maka perlu dibaca langsung dan ditelusuri cara kerjanya

Bacaan terkait

4 komentar

 
unsure4000 2 jam lalu

Diposting pada waktu yang mirip, tapi suasananya sangat berbeda jadi lucu juga wkwkwk
Pendapat saya tentang penulisan ulang Bun ke Rust
 
ffdd270 1 jam lalu

wkwkwkwkwkwkwkwkwkwkwkwkwkwkwkwkwkwk
 
GN⁺ 5 jam lalu
Komentar di Lobste.rs

  • Wawancaranya bagus, dan kalimat yang paling saya suka adalah “saya tidak sepenuhnya setuju, tetapi saya sangat menghormati keanehan yang percaya diri”
    Saya berharap sikap seperti ini lebih banyak muncul

  • Kalau membicarakan preseden dan evolusi terminal, rasanya Arcan dan cat9 setidaknya perlu disebut
    https://arcan-fe.com/2022/04/…

  • Bagian “PowerShell pandai menangani data terstruktur” membuat saya teringat pada jawaban Jörg W Mittag ini
    Jika menggunakan argumen bertipe, seluruh parsing ditangani oleh PowerShell
    Membayangkan tab Neovim terbuka sekaligus sebagai tab jendela native juga benar-benar keren
    Bekerja tepat di atas lapisan system call seperti C, Zig, dan Rust sangat membantu untuk memahami apa yang sebenarnya terjadi
    Proses mengupas abstraksi antara mesin dan programmer hingga menyentuh lapisan dasar itu menyenangkan, dan membuat kita lebih dekat dengan inti masalah
    Karena standard library biasanya menargetkan portabilitas, isinya cenderung menjadi penyebut bersama terkecil dari fitur sistem operasi; programming terasa jauh lebih menyenangkan ketika kita bisa memanfaatkan platform semaksimal mungkin
    Saya sangat menghormati sikap bahwa fungsi standard library pun adalah kode yang ditulis seseorang, jadi jangan anggap begitu saja dan bacalah
    Saya juga ingin tahu lebih banyak tentang program sponsorship Ghostty. Sepertinya ia dibentuk sebagai badan hukum nirlaba, dan saya penasaran seberapa berhasil serta seberapa mampu berdiri sendiri

  • PowerShell di Windows punya keunggulan karena, menurut definisi ini, ia sepenuhnya internal, tetapi karena dibangun di atas .NET framework dan bisa mengakses serta berinteroperasi dengan hampir semua Windows API, dalam praktiknya ia tidak terlalu terbatas
    UNIX secara desain bersifat eksternal, sementara jawaban terstruktur Nushell, sejauh yang saya pahami, bersifat internal secara ketat sehingga kurang dapat diperluas
    Oils bertaruh pada json atau ekstensi miliknya sendiri, json8 untuk interoperabilitas terstruktur eksternal, tetapi keduanya terasa cukup terbatas dibanding PowerShell
    Saya bertanya-tanya bagaimana kalau semua orang sepakat hanya mengirim sesuatu seperti msgpack lewat stdout dan menjadikan semua terminal sebagai viewer msgpack. Rasanya kita perlu membuat petisi agar serialisasi/deserialisasi pipe dimasukkan ke libc
    Bukan hanya badan standardisasi terminal yang menghilang; dunia shell juga hampir tidak punya inovasi menurut standar produksi
    Bash masih menambahkan fitur yang sudah ada di Kornshell, shell Unix punya terlalu banyak jebakan yang tidak ada yang tahu cara menghilangkannya, dan POSIX nyaris tidak bergerak
    Saya masih berpegang pada mimpi bahwa Oils atau Nushell diadopsi oleh distro-distro besar sehingga orang menyadari bahwa inovasi di area ini adalah hal baik
    Meski begitu, kitty jelas sudah membuka jalan di ranah terminal, dan meskipun koordinasinya kurang, sepertinya kita sudah sampai pada tahap di mana inovasi terjadi

  • Saya jadi sangat menghormati penilaian Mitchell yang tenang, baik positif maupun negatif
    Ia membuat terminal yang hebat dan menyukai antarmuka terminal, tetapi tidak setuju bahwa terminal harus melakukan segalanya atau didorong sampai ekstrem
    Ia sangat peduli pada bahasa pemrograman dan komunitasnya serta ingin tiap bahasa punya karakter unik, tetapi juga tahu bahwa bahasa pada akhirnya hanyalah sarana untuk mencapai tujuan dan pemahaman atas fondasinya lebih penting
    Ia mengakui bahwa secara pribadi ia tidak menyukai komunitas Rust, tetapi tidak merendahkan orang yang merasa berbeda
    Sikapnya yang melihat internet sebagai kumpulan berbagai suku, tetapi tidak terjebak dalam tribalisme atau pencarian “suku paling benar satu-satunya”, terasa cukup seperti Zen dan mengesankan

  • Saya setuju dengan gagasan bahwa perlu ada lebih banyak fork pribadi/pemeliharaan, tetapi saya tidak begitu tahu bagaimana mendorongnya
    Di sisi rendah dari spektrum rasa berhak, orang mungkin tidak tertarik pada hal-hal korporat seperti kontrak dukungan berbayar, dan hanya menginginkan kemudahan memasang langsung dari package manager favorit mereka
    Kita perlu entah bagaimana mengurangi friksi awal ketika berpindah dari brew install atau apt install ke tahap menangani repositori hasil clone dan build tools
    Compiler yang lebih cepat bisa membantu
    Namun untuk software yang sensitif terhadap keamanan, bisa jadi lebih menguntungkan jika pengguna tidak membuat terlalu banyak perubahan, sehingga friksi itu sendiri kadang merupakan fitur

  • Saya sangat setuju bahwa UI modern membutuhkan sesuatu yang berada kira-kira di antara n-screen dan spesifikasi tombol
    Mungkin cukup menyebutnya lapisan semantik
    Dengan lapisan ini, hal-hal seperti alat berbasis agen atau alat layar utama, aksesibilitas, serta widget dan kontrol yang dapat dikomposisikan menjadi mungkin
    n-screen dan tombol pada akhirnya tampak seperti batas kiri dan kanan dari seberapa banyak hal yang bisa diekspresikan
    Idealnya, lapisan semantik ini juga membawa hal-hal seperti multi-cursor, word wrap berbasis kata alih-alih line break per karakter, dan overlay (z-index, cell blending, dll.)