Tôi nhìn thấy tương lai trong jj

 (steveklabnik.com)
12 điểm bởi GN⁺ 2025-10-24 | 2 bình luận | Chia sẻ qua WhatsApp
  • Hệ thống quản lý phiên bản jj mới là một dự án được viết bằng Rust, là công cụ có cấu trúc cho phép áp dụng dần dần đồng thời khắc phục những giới hạn hiện có của Git
  • Dựa trên kinh nghiệm từng phân tích tiềm năng tăng trưởng của Rust trong quá khứ, tác giả đánh giá rằng jj cũng có tiềm năng tương tự ở các khía cạnh độ phù hợp với thị trường, đội ngũ chuyên môn và nền tảng người dùng
  • jj tương thích với kho lưu trữ Git nhưng vẫn cung cấp quy trình làm việc đơn giản hơn, nên đặc biệt dễ tiếp cận với những lập trình viên không quen với cấu trúc nội bộ của Git
  • Việc sử dụng thực tế đang lan rộng tại Google, Oxide và những nơi khác, đồng thời một cộng đồng đầy nhiệt huyết cùng đội ngũ phát triển tận tâm đang hình thành
  • Tác giả gia nhập ERSC, công ty đang phát triển nền tảng cộng tác dựa trên jj, và dự định trực tiếp thúc đẩy sự phát triển của hệ sinh thái jj giống như thời kỳ đầu của Rust

Lý do tôi đã chọn Rust

  • Tác giả bắt đầu quan tâm đến ngôn ngữ này sau khi thấy tin “Rust 0.5 released” trên Hacker News vào dịp Giáng Sinh năm 2012
    • Khi đó tác giả là một lập trình viên Ruby on Rails, nhưng từ thời đại học đã hứng thú với trình biên dịch và lập trình hệ thống
  • Khi đánh giá khả năng thành công của Rust, tác giả cân nhắc ba yếu tố: độ phù hợp với thị trường, đội ngũ phát triển, nền tảng người dùng
    • Không có ngôn ngữ đáng tin cậy nào để thay thế C/C++, còn Rust đưa ra cách tiếp cận đột phá khi cung cấp an toàn bộ nhớ mà không cần garbage collection
    • Vì có Mozilla tài trợ và kế hoạch đưa Rust vào Firefox, tác giả cho rằng khả năng xây dựng nền tảng sử dụng thực tế là rất cao
  • Bầu không khí thân thiện và hợp tác của cộng đồng Rust cũng là một yếu tố hấp dẫn
    • Sau đó, tác giả viết tutorial “Rust for Rubyists” và tham gia với vai trò đồng tác giả tài liệu chính thức

Sự xuất hiện của jj

  • jj (Jujutsu) không phải là ngôn ngữ lập trình mà là một hệ thống quản lý phiên bản (VCS) mới, được triển khai bằng Rust
    • Nó tương thích với Git, cho phép áp dụng dần dần trong khi vẫn sử dụng nguyên trạng các kho lưu trữ hiện có
  • Tác giả bắt đầu tìm hiểu jj nhờ lời giới thiệu từ Rain, một lập trình viên có gu kỹ thuật tương đồng
    • Rain từng làm ở đội quản lý mã nguồn của Meta, nên lời giới thiệu của cô được xem là một tín hiệu đáng tin cậy
  • Tác giả tự thử nghiệm jj vào cuối tuần và bắt đầu một dự án viết tutorial
    • Cũng giống như khi học Rust, tác giả tiếp cận bằng cách viết ra để hệ thống hóa các khái niệm
    • Kết quả là tutorial đã nhận được phản hồi tích cực từ cộng đồng

Triển vọng tương lai của jj

  • Tác giả nhìn thấy ở jj một mô hình tăng trưởng tương tự thời kỳ đầu của Rust
    • Độ phù hợp với thị trường, năng lực đội ngũ và khả năng mở rộng người dùng đều rất tích cực
  • Về độ phù hợp với thị trường, Git vẫn đang chiếm ưu thế tuyệt đối, nhưng jj có thể xử lý nguyên trạng kho Git nên vẫn cho phép áp dụng từng phần
    • Ngay trong nội bộ Oxide, việc sử dụng đã lan rộng bắt đầu từ Rain đến mức xuất hiện cả kênh riêng dành cho jj
  • jj cũng đang được sử dụng trong nội bộ Google, và điều này được diễn giải là tín hiệu tương tự như khi Mozilla từng chấp nhận Rust
    • Ngay cả trong các monorepo quy mô lớn của Google (dựa trên backend Piper), một số dự án cũng đang dùng jj, và điều này đóng vai trò như bằng chứng tín nhiệm xã hội (social proof)
  • Dù vẫn có đường cong học tập, với những người không quen cấu trúc nội bộ của Git thì jj lại mang đến trải nghiệm trực quan và đơn giản hơn
    • Những chuyên gia Git sẽ cần thích nghi với các khái niệm mới, nhưng các lập trình viên thông thường thì làm quen khá nhanh
  • Cộng đồng jj đang phát triển với bầu không khí nhiệt huyết và thân thiện, gợi nhớ đến cộng đồng Rust thuở ban đầu

Đội ngũ và cộng đồng jj

  • Nhà sáng lập Martin đã tận tâm với việc phát triển jj trong thời gian dài, và gần đây đã chuyển từ tài khoản cá nhân sang tài khoản tổ chức chính thức đồng thời sắp xếp lại cơ chế quản trị
  • Các thành viên trong đội là những chuyên gia giàu kinh nghiệm phát triển công cụ kiểm soát mã nguồn, thể hiện thế mạnh ở định hướng kỹ thuật và quản lý chất lượng
  • Cộng đồng đang tăng trưởng nhanh nhờ phản hồi tích cực và hợp tác sôi nổi, đồng thời tái hiện lại năng lượng tích cực của cộng đồng Rust thời kỳ đầu

Thử thách mới: gia nhập ERSC

  • Tác giả quyết định rời Oxide để gia nhập startup ERSC đang phát triển nền tảng cộng tác dựa trên jj
    • Oxide là một nơi làm việc tuyệt vời, nhưng khát khao được tham gia sâu hơn vào hệ sinh thái jj là yếu tố quyết định
  • ERSC dự định xây dựng nền tảng cộng tác cho lập trình viên trên jj, và tác giả nhắc tới trường hợp GitHub từng khởi đầu với tên pháp nhân Logical Awesome để mô tả giai đoạn đầu tương tự
  • Sau khi hoàn thành công việc tại Oxide, tác giả sẽ nghỉ ngơi một thời gian rồi tập trung vào hoạt động cộng đồng jj và hoàn thiện tutorial
    • Tác giả báo trước việc mở rộng hoạt động trên Discord, viết blog theo loạt và đóng góp cho cộng đồng
  • Tác giả xem năm 2025 là một bước ngoặt mới, đồng thời bày tỏ sự biết ơn khi có thể thử sức với dự án mà mình thực sự đam mê

Kết luận

  • Tác giả tin chắc rằng jj có tiềm năng tái hiện quỹ đạo tăng trưởng của Rust
    • Tính tương thích với Git, khả năng áp dụng dần dần, đội ngũ tận tâm và cộng đồng năng động là những căn cứ cho nhận định đó
  • jj không chỉ là một công cụ đơn thuần mà còn cho thấy khả năng phát triển thành nền tảng đổi mới cách các lập trình viên cộng tác
  • Hành trình của tác giả bắt đầu từ Rust giờ đây đang tiếp tục mở sang một chương mới cùng với jj

Bài viết liên quan

2 bình luận

 
tujuc 2025-10-24

Đây là chủ đề đã xuất hiện nhiều lần rồi, nhưng có lẽ vẫn nên xem thử một lần.
 
GN⁺ 2025-10-24
Ý kiến trên Hacker News

  • Tôi đã nghiêm túc dùng thử jj khoảng hai lần. Khái niệm xung đột hạng nhất khá hay, nhưng trên thực tế tôi thao tác staging/commit thường xuyên hơn nhiều so với xử lý xung đột. Vì quen từ magit sang nên tôi thấy tính năng chia nhỏ và chọn hunk của jj quá bất tiện. Tôi cũng là người rebase khá thường xuyên, nên với các phím tắt rebase của magit thì thực ra tôi đã tận hưởng được phần lớn ưu điểm của jj rồi. Với người như tôi, nếu jj muốn vượt magit thì UX chọn hunk phải được cải thiện rất nhiều

    • Điểm cốt lõi ở jj là không nghĩ theo staging hay commit. Mọi thứ đều là thay đổi(change), và cần tư duy theo kiểu đánh dấu cha hoặc tổ tiên xa hơn bằng bookmark rồi squash vào đó, hoặc chuyển bookmark sang thay đổi tiếp theo
    • Tôi cũng rebase thường xuyên, nhưng không thích triết lý quản lý phiên bản quá nặng tính áp đặt của jj. Đặc biệt, tôi nghĩ việc che giấu quá nhiều thiết kế nội bộ với người mới không giúp ích cho việc học
    • Tôi tò mò cụ thể UX chọn hunk của magit như thế nào. Nó có vẻ không khác jj quá nhiều. Tôi đã dùng GitUp(gitup.co) lâu năm; UX của jj chưa hoàn toàn tự nhiên, nhưng có vẻ là vấn đề có thể giải quyết bằng cách tùy biến phím tắt
    • Nếu hiểu vì sao việc đặt một UX tốt lên trên Git lại quan trọng, thì bạn đã hiểu 95% triết lý của jj rồi
    • Trong jj vẫn có thể dùng git index. Chỉ cần đừng dùng các lệnh jj thay đổi git_head là được. Tôi đang tạo alias để commit từ các thay đổi đã staged (ví dụ config.toml)

  • Mỗi lần thấy một lựa chọn thay thế Git, tôi lại có chút cảm giác Luddite. Ngôn ngữ, framework và công cụ đã quá nhiều rồi. Ít nhất thì với VCS, thật may là đã có Git như một lời giải gần như phổ quát. jj có thể giải quyết được vấn đề nào đó, nhưng nghĩ tới gánh nặng cả ngành phải hỗ trợ đồng thời hai hệ thống thì tôi không thấy đó là lợi ích ròng

    • Tôi ghét sự thiếu thốn về UI của Git đến mức mong nó bị thay thế. Tôi muốn có một công cụ mới giải thích các khái niệm của Git tốt hơn
    • jj là một lựa chọn mà từng lập trình viên có thể tự quyết. Repo jj là siêu tập của repo git nên các công cụ hiện có không bị hỏng
    • Trước đây tôi từng làm ở một công ty dùng svn, và đã dùng Git trước thông qua git-svn. jj có vẻ đang đi theo cách tiếp cận tương tự. Không cần biết jj thì CI hay các công cụ hiện có vẫn chạy bình thường
    • Git là một yếu tố làm giảm năng suất, và trong thời đại coding dựa trên agent thì còn là vấn đề lớn hơn. Tôi không nghĩ jj đủ tính đột phá. Thà cần một VCS mới theo dõi thay đổi ở mức nguyên tử(atomic) còn hơn. Với cấu trúc đó, khái niệm branch sẽ biến mất và trạng thái repo có thể được cấu thành từ plan và atom. Tuy nhiên, chuyển sang một hệ thống như vậy sẽ là thách thức cực lớn
    • Cũng như đã đi từ rcs, cvs, svn đến git, rồi git một ngày nào đó cũng sẽ bị thay thế bởi thứ tốt hơn

  • Tôi đã dùng jj, nhưng tôi quen với Sublime Merge hơn. Làm quản lý phiên bản bằng CLI thì phải gõ lặp đi lặp lại nhiều và dễ mất trạng thái. Trên GUI, trạng thái luôn hiện sẵn và chỉ cần một cú nhấp là xem diff hoặc nhập message commit được. Tôi không bao giờ muốn quay lại chọn hunk bằng bàn phím nữa. SM thực sự rất dễ chịu. Mong là GUI cho jj sẽ phát triển hơn hoặc jj được tích hợp vào SM

  • Tin tức thực sự là mọi người đã bắt đầu làm những thứ như “jjhub” (ersc.io)

    • Tôi nghĩ ‘jjhub’ là một bước đi đầu tiên khá ổn. Dù hiện đã có thể dùng jj cùng github, nhưng vẫn cần cung cấp một thứ gì đó có giá trị hơn thế
    • Nhân tiện, còn có cái này: bài blog về Stacking
    • Gerrit cũng rất hợp với các khái niệm của jj, và RFC bổ sung hỗ trợ Jujutsu change ID đã được thông qua
    • Cái tên jjhub nghe khá hay
    • Tôi thực sự hy vọng nó thành công. Đã đến lúc có một đối thủ thực sự của Github

  • Nghe nói jj đang lan rộng trong nội bộ Google, nhưng Google có xu hướng định kỳ thay đổi VCS nội bộ. Từ git wrapper, mercurial bản mở rộng, rồi giờ đến jj, tất cả đều đã thay đổi trong vòng 7 năm

    • Thực ra phần lớn công cụ nội bộ ở Google đều có tuổi thọ ngắn. Dù vậy, jj mang tính đột phá ở chỗ nó giữ được danh tính(identity) của thay đổi. Trong git, sau rebase hay amend thì commit trở thành thứ hoàn toàn khác, còn trong jj thì vẫn được theo dõi như cùng một thay đổi. Tuy vậy, có lẽ jj cuối cùng vẫn sẽ tiếp tục dùng git làm backend lưu trữ
    • Tôi mong jj sẽ tiếp tục được duy trì. Tôi muốn dùng cùng một workflow ở công ty và ở nhà. Nó nhanh hơn mercurial rất nhiều
    • Có vẻ lần này họ cũng định loại bỏ luôn cả bản fork của Perforce. Từ bên ngoài nhìn vào thì thay đổi quá nhiều
    • git wrapper ban đầu vốn chỉ là thử nghiệm, còn hệ thống dựa trên mercurial đã được duy trì gần 10 năm

  • Tôi tò mò không biết jj có xử lý các tệp nhị phân dung lượng lớn tốt hơn git không. Trong mảng phát triển game thì Perforce vẫn là vua. git dù có LFS cũng vẫn chưa đủ

    • Hỗ trợ file nhị phân của Perforce thực chất gần như giống hệt Git LFS. Khác biệt chủ yếu là có hỗ trợ doanh nghiệp hay không
    • jj dùng git làm kho lưu trữ và không hỗ trợ LFS, nên ở điểm này nó có cùng giới hạn như git
    • Hiện tại chưa có cải tiến đặc biệt nào, nhưng họ có nhận thức về mảng này và tương lai có thể sẽ thay đổi

  • Tôi đã dành khoảng một ngày làm theo tutorial Jujutsu và thấy khá ổn. Nhưng vẫn có cảm giác như thiếu một mảnh ghép còn thiếu. Ví dụ, tôi tự hỏi khi mở PR lên GitHub thì change id có thực sự hữu ích không. Có lẽ nó chỉ thật sự phát huy giá trị với backend Piper nội bộ của Google. Tôi tò mò về kế hoạch của ERSC. Cá nhân tôi muốn một workflow phân tán có review code ngoại tuyến được tích hợp sẵn

    • Rất vui vì bạn đã thấy nó thú vị :) Hiện tại trên GitHub gần như không có lợi ích nào từ change id. Nhưng với những công cụ như jj-spr thì có thể có được một phần trải nghiệm đó. Cũng từng có tweet nói rằng SVP của GitHub đã tỏ ra quan tâm tới jj. Ngoài ra, tôi đã thử một hệ thống đưa issue vào ngay trong repo là beads và khá thích nó
    • Các commit được tạo bằng jj có chứa header change-id, nên dù GitHub không biết jj là gì thì giữa những người dùng jj với nhau vẫn có thể theo dõi rebase. Có thể kiểm tra bằng git cat-file -p HEAD

  • Tôi đã dùng jj cho dự án cá nhân khoảng 1~2 tháng và khá hài lòng. Tuy vậy, khi sửa các revision cũ thì những file mới được thêm vào .gitignore có thể bị đưa vào nhầm. Ngoài chuyện đó ra thì ổn. Dù sao hiện tại tôi vẫn biết Git nhiều hơn hẳn, nên sẽ từ từ đưa nó vào công ty

  • Năm nay tôi gia nhập công ty Sapling/Subversion nhưng vẫn chưa dùng jj. Tuy vậy, Sapling trực quan hơn nhiều, và stack commit dễ hiểu hơn branch. Chỉ là tôi không biết sẽ ra sao nếu không có kiểu hỗ trợ như UI review của Meta. Dù sao thì những dự án như thế này là rất cần thiết

    • Đúng vậy, Sapling và jj là những dự án đồng hành đi cùng một hướng

  • Dù tên gọi là gì đi nữa thì East River Source Control vẫn là một cái tên cực ngầu