ฉันมองเห็นอนาคตใน jj

 (steveklabnik.com)
12 คะแนน โดย GN⁺ 2025-10-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบควบคุมเวอร์ชัน jj แบบใหม่เป็นโครงการที่เขียนด้วย Rust เป็นเครื่องมือที่ออกแบบมาเพื่อเสริมข้อจำกัดของ Git เดิม และมีโครงสร้างที่รองรับการนำไปใช้แบบค่อยเป็นค่อยไป
  • ผู้เขียนประเมินว่า jj มีศักยภาพคล้ายกับ Rust จากประสบการณ์ที่เคยวิเคราะห์โอกาสการเติบโตของ Rust มาก่อน โดยเฉพาะในด้าน ความเหมาะสมกับตลาด ทีมงานผู้เชี่ยวชาญ และฐานผู้ใช้
  • jj เข้ากันได้กับที่เก็บ Git พร้อมมอบเวิร์กโฟลว์ที่เรียบง่ายกว่า จึงเข้าถึงได้ง่ายเป็นพิเศษสำหรับนักพัฒนาที่ไม่ได้คุ้นเคยกับโครงสร้างภายในของ Git
  • มีการใช้งานจริงเพิ่มขึ้นที่ Google และ Oxide เป็นต้น และกำลังก่อรูปเป็น ชุมชนที่เต็มไปด้วยความกระตือรือร้นและทีมพัฒนาที่ทุ่มเท
  • ผู้เขียนตัดสินใจเข้าร่วม ERSC ซึ่งกำลังพัฒนาแพลตฟอร์มการทำงานร่วมกันบน jj และมีแผนจะช่วยผลักดันการเติบโตของระบบนิเวศ jj โดยตรงเหมือนในยุคแรกของ Rust

เหตุผลที่เคยเลือก Rust

  • ผู้เขียนเริ่มสนใจภาษา Rust หลังเห็นข่าว “Rust 0.5 released” บน Hacker News ในวันคริสต์มาสปี 2012
    • ตอนนั้นเป็นนักพัฒนา Ruby on Rails แต่ก็สนใจ คอมไพเลอร์และการเขียนโปรแกรมระบบ มาตั้งแต่สมัยมหาวิทยาลัย
  • ตอนประเมินโอกาสสำเร็จของ Rust ผู้เขียนพิจารณา 3 ปัจจัยคือ ความเหมาะสมกับตลาด ทีมพัฒนา และฐานผู้ใช้
    • ในเวลานั้นยังไม่มีภาษาที่น่าเชื่อถือพอจะมาแทน C/C++ และ Rust ก็เสนอแนวทางที่แปลกใหม่ด้วย ความปลอดภัยของหน่วยความจำโดยไม่ต้องใช้ garbage collection
    • Mozilla เป็นผู้สนับสนุนและมีแผนจะนำ Rust ไปใช้กับ Firefox จึงมองว่ามีโอกาสสูงที่จะสร้างฐานการใช้งานจริงได้
  • บรรยากาศของชุมชน Rust ที่ เป็นมิตรและร่วมมือกัน ก็เป็นอีกปัจจัยที่ดึงดูดใจ
    • ต่อมาผู้เขียนได้เขียนบทเรียน “Rust for Rubyists” และกลายเป็นผู้ร่วมเขียนเอกสารทางการ

การมาของ jj

  • jj (Jujutsu) ไม่ใช่ภาษาโปรแกรม แต่เป็น ระบบควบคุมเวอร์ชัน (VCS) แบบใหม่ ที่พัฒนาด้วย Rust
    • มันเข้ากันได้กับ Git และสามารถนำมาใช้แบบค่อยเป็นค่อยไปได้โดยยังใช้ที่เก็บเดิมต่อไป
  • ผู้เขียนเริ่มสำรวจ jj จากคำแนะนำของนักพัฒนา Rain ซึ่งมีรสนิยมทางเทคนิคใกล้เคียงกัน
    • Rain เคยอยู่ทีม source management ของ Meta ทำให้คำแนะนำของเธอถูกมองว่าเป็นสัญญาณที่เชื่อถือได้
  • ผู้เขียนทดลองใช้ jj ด้วยตัวเองในช่วงสุดสัปดาห์และเริ่มโครงการ เขียนบทเรียน
    • เหมือนตอนเรียน Rust คือใช้การเขียนเพื่อจัดระเบียบความเข้าใจในแนวคิดต่าง ๆ
    • ผลลัพธ์คือบทเรียนดังกล่าวได้รับการตอบรับเชิงบวกจากชุมชน

แนวโน้มอนาคตของ jj

  • ผู้เขียนมองเห็น รูปแบบการเติบโต ใน jj ที่คล้ายกับ Rust ยุคแรก
    • ทั้งความเหมาะสมกับตลาด ความสามารถของทีม และศักยภาพในการขยายผู้ใช้ ล้วนดูเป็นบวก
  • ในมุมของ ความเหมาะสมกับตลาด แม้ Git จะมีอำนาจเหนือกว่าอย่างชัดเจน แต่ jj ก็สามารถจัดการที่เก็บ Git เดิมได้ จึงรองรับ การนำไปใช้บางส่วน ได้
    • ภายใน Oxide เอง การใช้งานก็แพร่กระจายจาก Rain ไปจนได้รับความสนใจมากพอที่จะมีช่องเฉพาะ
  • Google ก็ใช้งาน jj ภายในองค์กรเช่นกัน และผู้เขียนตีความว่านี่เป็นสัญญาณคล้ายกับตอนที่ Mozilla รับ Rust ไปใช้
    • แม้แต่ใน monorepo ขนาดใหญ่ของ Google (บนแบ็กเอนด์ของ Piper) ก็มีบางโปรเจ็กต์ที่ใช้ jj ซึ่งทำหน้าที่เป็น หลักฐานความน่าเชื่อถือทางสังคม (social proof)
  • แม้จะมีเส้นโค้งการเรียนรู้อยู่บ้าง แต่สำหรับผู้ใช้ที่ไม่คุ้นกับโครงสร้างภายในของ Git แล้ว jj กลับมอบ ประสบการณ์ใช้งานที่ตรงไปตรงมาและเรียบง่ายกว่า
    • ยิ่งเป็นผู้เชี่ยวชาญ Git มากเท่าไร ก็ยิ่งต้องปรับตัวกับแนวคิดใหม่ แต่สำหรับนักพัฒนาทั่วไปกลับคุ้นเคยได้เร็ว
  • ชุมชนของ jj กำลังเติบโตด้วยบรรยากาศที่ กระตือรือร้นและเป็นมิตร ซึ่งชวนให้นึกถึงชุมชน Rust ในระยะแรก

ทีมและชุมชนของ jj

  • ผู้ก่อตั้ง Martin ทุ่มเทกับการพัฒนา jj มาอย่างยาวนาน และเมื่อไม่นานมานี้ก็ย้ายจากบัญชีส่วนตัวไปสู่ บัญชีองค์กรทางการ พร้อมจัดระเบียบด้านการกำกับดูแล
  • สมาชิกทีมเป็น ผู้เชี่ยวชาญที่มีประสบการณ์สูงในการพัฒนาเครื่องมือควบคุมซอร์สโค้ด และมีจุดแข็งทั้งในด้านทิศทางเทคนิคและการควบคุมคุณภาพ
  • ชุมชนกำลังเติบโตอย่างรวดเร็วผ่านฟีดแบ็กและการร่วมมือกันอย่างคึกคัก พร้อมถ่ายทอด พลังบวกแบบเดียวกับชุมชน Rust ยุคแรก

ความท้าทายใหม่: เข้าร่วม ERSC

  • ผู้เขียนตัดสินใจ ออกจาก Oxide และเข้าร่วมสตาร์ตอัป ERSC ที่พัฒนาแพลตฟอร์มการทำงานร่วมกันบน jj
    • Oxide เป็นที่ทำงานที่ยอดเยี่ยม แต่ความปรารถนาที่จะมีส่วนร่วมกับระบบนิเวศ jj อย่างลึกซึ้งยิ่งขึ้นเป็นปัจจัยชี้ขาด
  • ERSC วางแผนจะสร้าง แพลตฟอร์มการทำงานร่วมกันสำหรับนักพัฒนา บน jj โดยยกตัวอย่างช่วงเริ่มต้นของ GitHub ที่เริ่มต้นในชื่อบริษัท Logical Awesome เพื่ออธิบายว่าบริษัทยังอยู่ในระยะตั้งต้นคล้ายกัน
  • ผู้เขียนวางแผนจะปิดงานที่ Oxide ให้เรียบร้อย พักผ่อนสักระยะ แล้วค่อยทุ่มเทให้กับกิจกรรมในชุมชน jj และทำบทเรียนให้เสร็จสมบูรณ์
    • มีการบอกใบ้ถึงการขยายกิจกรรมบน Discord การเขียนบล็อกต่อเนื่อง และการมีส่วนร่วมกับชุมชนมากขึ้น
  • ผู้เขียนมองปี 2025 ว่าเป็น จุดเปลี่ยนครั้งใหม่ และแสดงความขอบคุณที่ได้มีโอกาสท้าทายตัวเองกับโครงการที่รู้สึกหลงใหลอย่างแท้จริง

บทสรุป

  • ผู้เขียนเชื่อมั่นว่า jj มี ศักยภาพที่จะเดินตามเส้นทางการเติบโตของ Rust
    • เหตุผลคือความเข้ากันได้กับ Git ความสามารถในการนำไปใช้แบบค่อยเป็นค่อยไป ทีมงานที่ทุ่มเท และชุมชนที่มีชีวิตชีวา
  • jj อาจเติบโตไปไกลกว่าการเป็นเพียงเครื่องมือ และแสดงให้เห็นความเป็นไปได้ในการพัฒนาเป็น แพลตฟอร์มนวัตกรรมสำหรับวิธีการทำงานร่วมกันของนักพัฒนา
  • การเดินทางของผู้เขียนที่เริ่มต้นจาก Rust กำลังต่อยอดไปสู่บทใหม่ร่วมกับ jj

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
tujuc 2025-10-24

เป็นเรื่องที่พูดถึงกันมาหลายครั้งแล้ว แต่เหมือนต้องลองอ่านดูสักครั้งนะ
 
GN⁺ 2025-10-24
ความเห็นจาก Hacker News

  • ฉันเคยลองใช้ jj แบบจริงจังอยู่ราวสองครั้ง แนวคิด first-class conflict นั้นเท่มาก แต่ในทางปฏิบัติกลับต้องทำ staging/commit บ่อยกว่าการแก้ conflict มาก พอย้ายมาจาก magit ก็รู้สึกว่าฟีเจอร์แบ่งและเลือก hunk ของ jj ใช้งานไม่สะดวกเอามาก ๆ ฉันเป็นคนที่ rebase บ่อยอยู่แล้ว เลยได้ประโยชน์หลัก ๆ ของ jj ไปเกือบหมดจาก shortcut สำหรับ rebase ของ magit สำหรับคนแบบฉัน ถ้า jj จะชนะ magit ได้ UX ของการเลือก hunk ต้องดีขึ้นอีกมาก

    • หัวใจสำคัญของ jj คือไม่ต้องคิดเรื่อง staging หรือ commit ทุกอย่างคือ change และควรคิดในแบบตั้ง bookmark ไว้ที่ parent หรือ ancestor ที่ไกลกว่านั้น แล้ว squash เข้าไปในนั้น หรือย้าย bookmark ไปยัง change ถัดไป
    • ฉันก็ rebase บ่อยเหมือนกัน แต่ไม่ชอบ ปรัชญาการจัดการเวอร์ชันที่ชี้นำมากเกินไป ของ jj โดยเฉพาะการซ่อนการออกแบบภายในจากมือใหม่มากเกินไป ฉันคิดว่ามันไม่ได้ช่วยให้เรียนรู้ดีขึ้น
    • อยากรู้ว่า UX การเลือก hunk ของ magit เป็นอย่างไรแบบเฉพาะเจาะจง เพราะของ jj ก็ดูไม่ได้ต่างกันมาก ฉันใช้ GitUp(gitup.co) มานาน แม้ UX ของ jj จะยังไม่เป็นธรรมชาติเต็มที่ แต่ก็ดูเหมือนเป็นปัญหาที่แก้ได้ด้วยการปรับแต่งคีย์ลัด
    • ถ้าคุณเข้าใจว่าทำไมการวาง UX ที่ดี บน Git ถึงสำคัญ ก็เท่ากับคุณเข้าใจปรัชญาของ jj ไปแล้ว 95%
    • ใน jj ก็ใช้ git index ได้ ตราบใดที่ไม่ใช้คำสั่ง jj ที่เปลี่ยน git_head ฉันทำ alias สำหรับ commit จาก staged changes ใช้อยู่ (ตัวอย่าง config.toml)

  • ทุกครั้งที่เห็นทางเลือกแทน Git ฉันจะรู้สึก ลัดไดต์ นิด ๆ ตอนนี้มีทั้งภาษา เฟรมเวิร์ก และเครื่องมือมากเกินไปแล้ว อย่างน้อยในเรื่อง VCS ก็ยังดีที่มีคำตอบที่แทบจะเป็นสากลอย่าง Git ถึง jj อาจจะแก้ปัญหาได้ แต่พอคิดถึงภาระที่ทั้งอุตสาหกรรมต้องรองรับสองระบบพร้อมกันแล้ว ก็ดูไม่น่าจะได้ประโยชน์สุทธิ

    • ฉันรำคาญ UI ที่แย่มากของ Git จนอยากให้มันถูกแทนที่ อยากได้เครื่องมือใหม่ที่อธิบายแนวคิดของ Git ได้ดีกว่านี้
    • jj เป็นตัวเลือกที่นักพัฒนาแต่ละคนเลือกใช้เองได้ repo ของ jj เป็น superset ของ git repo ดังนั้นเครื่องมือเดิมจะไม่พัง
    • ฉันเคยอยู่บริษัทที่ใช้ svn มาก่อน แล้วเริ่มใช้ Git ผ่าน git-svn ก่อน ดูเหมือน jj จะใช้แนวทางคล้ายกัน ต่อให้ไม่รู้จัก jj, CI หรือเครื่องมือเดิมก็ยังทำงานเหมือนเดิม
    • Git เป็น ตัวถ่วงประสิทธิภาพการทำงาน และยิ่งเป็นปัญหาใหญ่ขึ้นในยุคของ agent-based coding ฉันมองว่า jj ยังไม่ปฏิวัติพอ ทางที่ดีกว่าน่าจะเป็น VCS แบบใหม่ที่ติดตามการเปลี่ยนแปลงในระดับ atomic ถ้าเป็นโครงสร้างแบบนั้น แนวคิดเรื่อง branch จะหายไป และสถานะของ repo จะประกอบจาก plan กับ atom ได้แทน แต่การย้ายไปสู่ระบบแบบนั้นคงเป็นความท้าทายมหาศาล
    • อย่างที่มี rcs, cvs, svn แล้วค่อยมาเป็น git สักวันหนึ่ง git ก็คงถูกแทนที่ด้วยสิ่งที่ดีกว่า

  • ฉันเคยใช้ jj แต่คุ้นกับ Sublime Merge มากกว่า ถ้าจัดการเวอร์ชันผ่าน CLI มันต้องพิมพ์อะไรซ้ำ ๆ เยอะและหลุดสถานะได้ง่าย แต่ใน GUI จะเห็นสถานะตลอด และคลิกครั้งเดียวก็ดู diff หรือพิมพ์ข้อความ commit ได้แล้ว ฉันไม่อยากกลับไปเลือก hunk ด้วยคีย์บอร์ดอีกแล้ว SM ใช้งานสบายมาก หวังว่า GUI ของ jj จะพัฒนาขึ้น หรือไม่ก็ให้ SM รวม jj เข้าไปเลย

  • ข่าวจริงคือผู้คนเริ่มสร้างของอย่าง “jjhub” แล้ว (ersc.io)

    • ฉันคิดว่า ‘jjhub’ เป็นก้าวแรกที่ดี ตอนนี้ก็ใช้ jj คู่กับ github ได้อยู่แล้ว แต่ถ้าจะไปไกลกว่านั้น มันต้องมี บางอย่างที่มีคุณค่า เพิ่มเข้ามา
    • เผื่อสนใจ ยังมีอันนี้ด้วย: บทความบล็อก Stacking
    • Gerrit ก็เข้ากับแนวคิดของ jj ได้ดี และ RFC สำหรับเพิ่มการรองรับ Jujutsu change ID ก็ได้รับการอนุมัติแล้ว
    • ชื่อ jjhub นี่เท่มาก
    • หวังจากใจว่าจะสำเร็จ ถึงเวลาแล้วที่จะมี ทางเลือกแท้จริงของ Github

  • ได้ยินมาว่า jj กำลังแพร่หลายภายใน Google แต่ Google เองก็มีแนวโน้มจะเปลี่ยน VCS ภายในเป็นระยะ ๆ ทั้ง git wrapper, mercurial แบบขยาย, ตอนนี้ก็ jj อีก ภายใน 7 ปีก็เปลี่ยนมาหมดแล้ว

    • จริง ๆ แล้วเครื่องมือภายในของ Google ส่วนใหญ่ก็อายุไม่ยืนอยู่แล้ว ถึงอย่างนั้น jj ก็ถือว่านวัตกรรมตรงที่มันรักษา อัตลักษณ์ของการเปลี่ยนแปลง(identity) ไว้ได้ ใน git หลัง rebase หรือ amend แล้วมันจะกลายเป็น commit คนละตัวไปเลย แต่ jj ยังติดตามว่าเป็น change เดิมได้ อย่างไรก็ดี สุดท้าย jj ก็น่าจะยังใช้ git เป็น storage backend ต่อไป
    • หวังว่า jj จะอยู่ต่อไปเรื่อย ๆ อยากใช้ workflow เดียวกันทั้งที่บริษัทและที่บ้าน มันเร็วกว่่า mercurial มาก
    • คราวนี้ดูเหมือนตั้งใจจะเลิกใช้ Perforce fork ไปพร้อมกันด้วย จากคนนอกมองเข้าไป การเปลี่ยนแปลงมันเยอะเกินไป
    • git wrapper เดิมทีเป็นแค่การทดลอง และระบบที่อิง mercurial ก็ถูกใช้งานอยู่นานเกือบ 10 ปี

  • อยากรู้ว่า jj จัดการ ไฟล์ไบนารีขนาดใหญ่ ได้ดีกว่า git ไหม ฝั่งพัฒนาเกม Perforce ก็ยังเป็นเจ้าตลาดอยู่ git ต่อให้มี LFS ก็ยังไม่พอ

    • การรองรับไฟล์ไบนารีของ Perforce นั้นจริง ๆ แล้ว แทบไม่ต่างจาก Git LFS เลย ความต่างหลัก ๆ ก็แค่เรื่องการซัพพอร์ตระดับองค์กร
    • jj ใช้ git เป็นที่เก็บข้อมูลและยังไม่รองรับ LFS ดังนั้นในจุดนี้ก็มีข้อจำกัดแบบเดียวกับ git
    • ตอนนี้ยังไม่มีการปรับปรุงพิเศษอะไร แต่ก็รับรู้ปัญหาในพื้นที่นี้อยู่ และอาจมีการเปลี่ยนแปลงในอนาคต

  • ฉันลองทำตาม Jujutsu tutorial อยู่ประมาณวันหนึ่งแล้วรู้สึกว่ามันค่อนข้างดี แต่ก็เหมือนมี ชิ้นส่วนปริศนาที่หายไป อยู่ เช่น เวลาส่ง PR ไป GitHub แล้ว change id ช่วยอะไรได้จริงไหม ดูเหมือนมันจะปล่อยของได้เต็มที่เฉพาะกับ backend Piper ภายใน Google เท่านั้น ฉันอยากรู้ว่า ERSC วางแผนอะไรไว้ ส่วนตัวฉันอยากได้ workflow แบบกระจายศูนย์ที่มี offline code review มาในตัว

    • ดีใจที่คุณลองใช้แล้วสนุก :) ตอนนี้บน GitHub ข้อดีของ change id แทบไม่มีเลย แต่ก็พอได้ประสบการณ์บางส่วนจากเครื่องมืออย่าง jj-spr และเคยมีทวีตที่ GitHub SVP แสดงความสนใจใน jj ด้วย อีกอย่าง ฉันเคยลองใช้ beads ซึ่งเป็น ระบบเก็บ issue ไว้ใน repo แล้วก็ชอบมากทีเดียว
    • commit ที่สร้างด้วย jj จะมี header change-id อยู่ ดังนั้นถึง GitHub จะไม่รู้จัก jj ผู้ใช้ jj ด้วยกันก็ยังติดตามการ rebase ได้ ตรวจได้ด้วย git cat-file -p HEAD

  • ฉันใช้ jj กับโปรเจ็กต์ส่วนตัวมา 1~2 เดือนแล้ว และค่อนข้างพอใจ แต่เวลาย้อนกลับไปแก้ revision เก่า ไฟล์ที่เพิ่งเพิ่มเข้า .gitignore อาจถูกใส่รวมมาโดยไม่ตั้งใจได้ นอกนั้นก็ดีหมด ถึงอย่างนั้นตอนนี้ฉันก็ยัง มีความรู้เรื่อง Git มากกว่าเยอะ เลยจะค่อย ๆ เอาไปใช้ที่บริษัททีละน้อย

  • ปีนี้ฉันเพิ่งเข้าร่วม บริษัท Sapling/Subversion เลยยังไม่ได้ลอง jj แต่ Sapling นั้น เข้าใจง่าย กว่ามาก และแนวคิดเรื่อง commit stack ก็เข้าใจง่ายกว่า branch เพียงแต่ก็สงสัยว่าถ้าไม่มีเครื่องมือสนับสนุนอย่าง UI รีวิวของ Meta แล้วจะเป็นอย่างไร โปรเจ็กต์แบบนี้จำเป็นมากจริง ๆ

    • ใช่เลย Sapling กับ jj เป็นโปรเจ็กต์ร่วมทางที่มุ่งไปในทิศทางเดียวกัน

  • ไม่ว่าชื่อจะเป็นอะไร East River Source Control ก็เป็นชื่อที่เท่มากจริง ๆ