Saya Melihat Masa Depan di jj

 (steveklabnik.com)
12 poin oleh GN⁺ 2025-10-24 | 2 komentar | Bagikan ke WhatsApp
  • Sistem kontrol versi baru jj adalah proyek yang ditulis dalam Rust, sebuah alat dengan struktur yang melengkapi keterbatasan Git yang ada sekaligus memungkinkan adopsi bertahap
  • Berdasarkan pengalamannya dahulu menganalisis potensi pertumbuhan Rust, penulis menilai bahwa jj juga memiliki potensi serupa dari sisi kesesuaian pasar, tim ahli, dan basis pengguna
  • jj tetap kompatibel dengan repositori Git sambil menawarkan alur kerja yang lebih sederhana, sehingga lebih mudah diakses terutama bagi pengembang yang tidak akrab dengan struktur internal Git
  • Penggunaan nyata mulai meluas di Google dan Oxide, dan komunitas yang antusias serta tim pengembang yang berdedikasi juga mulai terbentuk
  • Penulis bergabung dengan ERSC, yang mengembangkan platform kolaborasi berbasis jj, dan berencana turut mendorong langsung pertumbuhan ekosistem jj seperti pada masa awal Rust

Alasan Memilih Rust

  • Penulis mulai tertarik pada bahasa ini setelah melihat kabar “Rust 0.5 released” di Hacker News pada hari Natal 2012
    • Saat itu ia adalah pengembang Ruby on Rails, tetapi sejak masa kuliah sudah tertarik pada kompiler dan pemrograman sistem
  • Saat menilai peluang keberhasilan Rust, ia mempertimbangkan tiga faktor: kesesuaian pasar, tim pengembang, dan basis pengguna
    • Tidak ada bahasa yang benar-benar dapat diandalkan untuk menggantikan C/C++, dan Rust menawarkan pendekatan inovatif berupa keamanan memori tanpa garbage collection
    • Karena didukung Mozilla dan ada rencana untuk menerapkan Rust di Firefox, ia menilai peluang terbentuknya basis penggunaan nyata cukup tinggi
  • Suasana komunitas Rust yang ramah dan kolaboratif juga menjadi faktor yang menarik
    • Setelah itu penulis menulis tutorial “Rust for Rubyists” dan ikut menjadi salah satu penulis dokumentasi resmi

Munculnya jj

  • jj(Jujutsu) bukan bahasa pemrograman, melainkan sistem kontrol versi (VCS) baru yang diimplementasikan dalam Rust
    • Kompatibel dengan Git dan dapat diadopsi secara bertahap sambil tetap memakai repositori yang ada
  • Penulis mulai mengeksplorasi jj setelah direkomendasikan oleh Rain, seorang pengembang dengan selera teknis yang mirip dengannya
    • Rain berasal dari tim source management Meta, sehingga rekomendasinya dianggap sebagai sinyal yang layak dipercaya
  • Pada akhir pekan, ia bereksperimen langsung dengan jj sambil memulai proyek penulisan tutorial
    • Sama seperti saat mempelajari Rust, ia mendekatinya dengan cara merapikan konsep sambil menulis
    • Hasilnya, tutorial tersebut mendapat respons positif dari komunitas

Prospek Masa Depan jj

  • Penulis melihat pola pertumbuhan pada jj yang mirip dengan masa awal Rust
    • Kesesuaian pasar, kemampuan tim, dan potensi penyebaran pengguna semuanya dinilai positif
  • Dari sisi kesesuaian pasar, Git memang berada pada posisi dominan mutlak, tetapi jj bisa menangani repositori Git apa adanya sehingga adopsi parsial dimungkinkan
    • Bahkan di internal Oxide, penggunaan menyebar mulai dari Rain hingga minatnya cukup tinggi sampai muncul kanal khusus
  • jj juga digunakan di internal Google, dan ini ditafsirkan sebagai sinyal yang mirip dengan ketika Mozilla mengadopsi Rust
    • Bahkan dalam monorepo besar Google (berbasis backend Piper), beberapa proyek sudah memakai jj, dan ini menjadi bukti kepercayaan sosial (social proof)
  • Ada kurva belajar, tetapi bagi pengguna yang tidak akrab dengan struktur internal Git, jj justru menawarkan penggunaan yang lebih intuitif dan sederhana
    • Semakin ahli seseorang dalam Git, semakin perlu ia beradaptasi dengan konsep baru, tetapi pengembang pada umumnya dapat cepat terbiasa
  • Komunitas jj sedang tumbuh dengan atmosfer yang antusias dan bersahabat, yang mengingatkan pada komunitas Rust pada masa awal

Tim dan Komunitas jj

  • Pendiri Martin telah lama mendedikasikan diri pada pengembangan jj, dan belakangan memindahkan proyek ini dari akun pribadi ke akun organisasi resmi sambil menata tata kelolanya
  • Anggota timnya adalah para ahli dengan banyak pengalaman dalam pengembangan alat source control, sehingga kuat dalam arah teknis dan pengelolaan kualitas
  • Komunitasnya tumbuh cepat melalui umpan balik aktif dan kolaborasi, sambil menghadirkan kembali energi positif komunitas Rust awal

Tantangan Baru: Bergabung dengan ERSC

  • Penulis memutuskan untuk meninggalkan Oxide dan bergabung dengan startup ERSC yang mengembangkan platform kolaborasi berbasis jj
    • Oxide adalah tempat kerja yang luar biasa, tetapi hasrat untuk terlibat lebih dalam dalam ekosistem jj menjadi faktor penentu
  • ERSC berencana membangun platform kolaborasi pengembang di atas jj, dan penulis menjelaskan tahap awal yang serupa dengan kisah GitHub yang berawal dengan nama badan hukum Logical Awesome
  • Setelah menyelesaikan pekerjaannya di Oxide, penulis berencana beristirahat lalu fokus pada aktivitas komunitas jj dan penyelesaian tutorial
    • Ia mengisyaratkan peningkatan aktivitas di Discord, serial blog, dan kontribusi komunitas lainnya
  • Ia menilai 2025 sebagai titik balik baru, dan mengungkapkan rasa syukur karena bisa menantang dirinya pada proyek yang benar-benar ia minati

Kesimpulan

  • Penulis yakin bahwa jj memiliki potensi untuk mengulangi lintasan pertumbuhan Rust
    • Kompatibilitas dengan Git, kemungkinan adopsi bertahap, tim yang berdedikasi, dan komunitas yang aktif menjadi alasannya
  • jj menunjukkan kemungkinan berkembang bukan sekadar sebagai alat, tetapi sebagai platform inovatif untuk cara pengembang berkolaborasi
  • Perjalanan penulis yang dimulai dari Rust kini berlanjut ke babak baru bersama jj

Bacaan terkait

2 komentar

 
tujuc 2025-10-24

Ini sudah beberapa kali muncul, jadi sepertinya perlu dilihat sekali.
 
GN⁺ 2025-10-24
Komentar Hacker News

  • Saya sudah dua kali mencoba memakai jj dengan serius. Konsep first-class conflict memang keren, tetapi dalam praktiknya saya jauh lebih sering melakukan staging/commit daripada menyelesaikan konflik. Karena datang dari magit, fitur pemisahan dan pemilihan hunk di jj terasa sangat tidak nyaman. Saya cukup sering melakukan rebase, jadi lewat shortcut rebase di magit saya sebenarnya sudah menikmati sebagian besar keunggulan jj. Bagi orang seperti saya, agar jj bisa mengungguli magit, UX pemilihan hunk harus jauh lebih ditingkatkan

    • Inti dari jj adalah tidak memikirkan staging atau commit. Semuanya adalah perubahan(change), dan Anda harus berpikir dengan cara seperti menetapkan parent atau leluhur yang lebih jauh sebagai bookmark, lalu melakukan squash ke sana atau memindahkan bookmark ke perubahan berikutnya
    • Saya juga sering melakukan rebase, tetapi saya kurang suka filosofi kontrol versi yang terlalu opinionated dari jj. Terutama untuk pemula, menurut saya terlalu menyembunyikan desain internal tidak membantu proses belajar
    • Saya penasaran seperti apa tepatnya UX pemilihan hunk di magit. Kelihatannya tidak terlalu berbeda besar dengan milik jj. Saya sudah lama memakai GitUp(gitup.co), dan meskipun UX jj tidak terasa sepenuhnya natural, rasanya itu masalah yang bisa diselesaikan dengan kustomisasi shortcut
    • Kalau Anda paham kenapa penting menaruh UX yang baik di atas Git, berarti Anda sudah memahami 95% filosofi jj
    • Di jj juga bisa memakai git index. Hanya saja jangan memakai perintah jj yang mengubah git_head. Saya membuat alias untuk melakukan commit dari perubahan yang sudah di-stage dan memakainya seperti itu (contoh config.toml)

  • Setiap kali melihat alternatif untuk Git, saya sedikit merasakan emosi Luddite. Bahasa, framework, dan tool sudah terlalu banyak. Setidaknya untuk VCS, saya senang ada solusi yang nyaris universal bernama Git. Mungkin jj bisa memecahkan masalah, tetapi jika memikirkan beban industri untuk mendukung dua sistem sekaligus, rasanya itu bukan keuntungan bersih

    • Saya sangat jengkel dengan buruknya UI Git dan berharap ada penggantinya. Saya ingin ada tool baru yang bisa menjelaskan konsep Git dengan lebih baik
    • jj adalah opsi yang bisa dipilih masing-masing developer. Repo jj adalah superset dari repo git, jadi tool yang ada tidak akan rusak
    • Dulu saya pernah di perusahaan yang memakai svn, dan kami lebih dulu memakai Git melalui git-svn. Sepertinya jj mengambil pendekatan serupa. Walaupun tidak tahu jj, CI dan tool yang ada tetap berjalan seperti biasa
    • Git adalah faktor penurun produktivitas, dan di era coding berbasis agen ini malah jadi masalah yang lebih besar. Menurut saya jj belum cukup revolusioner. Lebih baik ada VCS baru yang melacak perubahan secara atomic. Dengan struktur seperti ini, konsep branch akan hilang, dan status repo bisa disusun dari plan dan atom. Namun, berpindah ke sistem seperti itu akan menjadi tantangan yang sangat besar
    • Seperti git lahir setelah rcs, cvs, dan svn, git juga suatu hari akan digantikan oleh sesuatu yang lebih baik

  • Saya sudah mencoba jj, tetapi saya terbiasa dengan Sublime Merge. Saat melakukan version control lewat CLI, input berulang jadi banyak dan mudah kehilangan konteks. Di GUI, status selalu terlihat dan dengan satu klik kita bisa melihat diff atau menulis pesan commit. Saya tidak ingin lagi memilih hunk dengan keyboard. SM benar-benar nyaman. Akan bagus kalau GUI jj berkembang, atau jj terintegrasi ke SM

  • Berita yang sebenarnya adalah orang-orang mulai membuat sesuatu seperti “jjhub” (ersc.io)

    • Saya rasa ‘jjhub’ adalah langkah awal yang cukup bagus. Saat ini kita memang sudah bisa memakai jj bersama github, tetapi harus ada sesuatu yang lebih bernilai dari itu
    • Sebagai referensi, ada juga ini: posting blog tentang Stacking
    • Gerrit juga cocok sekali dengan konsep jj, dan RFC untuk menambahkan dukungan Jujutsu change ID sudah disetujui
    • Nama jjhub cukup keren
    • Saya sungguh berharap ini berhasil. Sudah waktunya muncul alternatif nyata untuk Github

  • Katanya jj sedang menyebar di internal Google, tetapi Google memang cenderung mengganti VCS internalnya secara berkala. Dalam 7 tahun mereka sudah berganti-ganti antara git wrapper, versi mercurial yang diperluas, dan sekarang jj

    • Sebenarnya sebagian besar tool internal Google berumur pendek. Meski begitu, jj tetap inovatif karena mempertahankan identitas(identity) perubahan. Di git, setelah rebase atau amend, itu menjadi commit yang benar-benar berbeda, tetapi di jj tetap dilacak sebagai perubahan yang sama. Namun, pada akhirnya jj kemungkinan besar akan tetap memakai git sebagai backend penyimpanan
    • Saya harap jj terus dipertahankan. Saya ingin memakai workflow yang sama di kantor dan di rumah. Jauh lebih cepat daripada mercurial
    • Sepertinya kali ini mereka juga berniat menghentikan fork Perforce. Dari luar, perubahan ini terlihat terlalu banyak
    • git wrapper pada awalnya memang eksperimental, dan sistem berbasis mercurial dipertahankan hampir 10 tahun

  • Saya penasaran apakah jj menangani file biner berukuran besar lebih baik daripada git. Di pengembangan game, Perforce masih jadi rajanya. git, bahkan dengan LFS, masih belum cukup

    • Dukungan biner di Perforce pada dasarnya sama dengan Git LFS. Bedanya mungkin hanya pada dukungan enterprise
    • jj memakai git sebagai repositori dan tidak mendukung LFS, jadi dalam hal ini ia punya keterbatasan yang sama dengan git
    • Untuk saat ini belum ada peningkatan khusus, tetapi area ini disadari dan mungkin akan ada perubahan ke depannya

  • Saya mengikuti tutorial Jujutsu selama sekitar sehari, dan kesannya cukup bagus. Tapi terasa seperti ada bagian puzzle yang hilang. Misalnya, saya penasaran apakah change id benar-benar membantu saat mengajukan PR ke GitHub. Mungkin nilainya baru benar-benar terasa di backend Piper internal Google. Saya penasaran dengan rencana ERSC. Secara pribadi, saya ingin workflow terdistribusi dengan code review offline yang terintegrasi

    • Senang mendengar Anda menikmatinya :) Saat ini di GitHub hampir tidak ada manfaat dari change id. Tetapi dengan tool seperti jj-spr, Anda bisa mendapatkan sebagian pengalaman itu. Ada juga tweet bahwa SVP GitHub menunjukkan ketertarikan pada jj. Selain itu, saya pernah mencoba beads, yaitu sistem yang menaruh issue di dalam repo, dan saya cukup menyukainya
    • Commit yang dibuat dengan jj menyertakan header change-id, jadi meskipun GitHub tidak memahami jj, sesama pengguna jj tetap bisa melacak rebase. Bisa dicek lewat git cat-file -p HEAD

  • Saya sudah memakai jj untuk proyek pribadi selama 1–2 bulan dan cukup puas. Namun, saat mengubah revisi lama, file yang baru ditambahkan ke .gitignore bisa ikut masuk tanpa sengaja. Selain itu semuanya bagus. Meski begitu, pengetahuan saya tentang Git masih jauh lebih banyak, jadi saya akan memperkenalkannya ke kantor pelan-pelan

  • Tahun ini saya bergabung dengan perusahaan Sapling/Subversion, dan belum sempat mencoba jj. Meski begitu, Sapling terasa jauh lebih intuitif, dan stack commit lebih mudah dipahami daripada branch. Tetapi saya penasaran bagaimana hasilnya tanpa dukungan seperti UI review milik Meta. Proyek seperti ini memang sangat dibutuhkan

    • Benar, Sapling dan jj adalah proyek searah yang saling sejajar

  • Apa pun namanya, East River Source Control adalah nama yang sangat keren