ハクソク

世界を動かす技術を、日本語で。

jjに未来を見出す

200日前原文(steveklabnik.com)

概要

  • Rust との出会いと選択理由の回顧
  • 新しいバージョン管理システム jj への興味と評価
  • jj の市場適合性・チーム・ユーザーベースの分析
  • Oxide から ERSC への転職決断と今後の展望
  • jj コミュニティへのさらなる貢献意欲

Rustとの出会いと選択理由

  • 2012年12月、 Hacker News で「Rust 0.5 released」を発見
  • 当時は Ruby と Rails に従事、大学時代はコンパイラ志望
  • 新しい刺激を求めて Rust に注目
  • 成功するプログラミング言語の条件を検討
    • 市場適合性： C/C++ の代替がほぼ存在せず、 Go や D も課題あり
    • チーム： Mozilla が開発を後押し、専任スタッフの存在が大きな強み
    • ユーザーベース： Firefox への導入計画、実用性と普及基盤の確立
  • Rust コミュニティの雰囲気が良好で、参加意欲を後押し
  • 「Rust for Rubyists」執筆や The Book 共著など、コミュニティ貢献

新しいバージョン管理システム「jj」への関心

  • jj は新しいバージョン管理システム（VCS）、 Rust 製
  • Meta 出身の Rain の推薦で興味を持つ
  • 初心者目線でのドキュメント執筆が理解促進に有効
  • jj チュートリアルが好評、学習と共有の好循環

jjの市場適合性・普及の可能性

  • Git が市場を席巻する中、 jj はGitリポジトリと互換性を持ち段階的導入が可能
  • 企業内でのスモールスタートが現実的な普及戦略
    • Oxide や Google での導入実績
    • Piper をバックエンドに利用、大規模モノレポでも実践例
  • jj は学習曲線はあるが、Gitに精通していない人にはむしろ習得が容易
  • 熱心なファン層とスキンクワークス的な採用が活発
  • 開発チームも経験豊富で、組織体制の強化とコミュニティの成長が進行中
  • 初期の Rust コミュニティのような前向きな雰囲気

OxideからERSCへの転職と今後

  • Oxide を退職し、 ERSC へ転職を決断
  • ERSC は jj 上に新しい開発者コラボレーションプラットフォームを構築予定
  • 新しい製品名は未定、GitHubのLogical Awesome的な立ち位置
  • 転職前に業務整理と休暇を挟み、今後は jj コミュニティへの貢献を拡大
  • チュートリアルの完成やDiscordでの活動強化を予定
  • 2025年は好調なスタート、新たな挑戦への高い意欲

今後の展望

  • jj に関するさらなる記事執筆を予告
  • BlueSky での発信も継続予定
  • 情熱 と 好奇心 に基づくキャリア選択の重要性強調

Hackerたちの意見

著者が最初にRustやGoについて話していた意図はなんとなくわかるけど、Jjのところに来たらめっちゃ混乱した。名前もひどいと思うけど、まあいいや。JjはVCSなんだけど、もっと読み進めるまで全然わからなかったし、ソース管理についてこんなに話す理由がわからなくて困惑した。最初はJjが言語だと思ってたからね。どうやらJjはgitリポジトリで使えるらしくて、段階的に導入しやすいのがいい点みたい。この記事の主なポイントは、著者がOxideを辞めて新しい会社でJjのGitHubを作ろうとしているってことらしい。私みたいに混乱している人の役に立てばいいな。

└

フィードバックありがとう！この話をたくさんしてるから、ブログの常連読者にはもう知ってることかもしれないけど、他の人に重要な文脈を抜かしたくないんだ。これを修正するために頑張ったよ。https://github.com/steveklabnik/steveklabnik.com/pull/125/fi...、改めてありがとう！

└

フルネームはJujutsuだけど、「jj」が先に来たと思う。「j」はQWERTYキーボードではホームローにあって、ちょっとした触覚マーカー（バンプ）がある2つのキーのうちの1つだから、いい感じだよね。

jj describe -m "頑張れ、スティーブ！"

今年、sapling/subversionの会社に入ったけど、まだjjを使う機会がなかった。でも、その見た目からして、saplingはすごく良かったよ。gitより直感的で、コミットスタックの方がブランチよりずっと追いやすい。Metaのサポートがないとどうなるか気になるけど、同じコミットスタックレビューUI（基本的には同時にレビューされるプルリクエストのシリーズ）がないからね。だから、著者が取り組んでいるようなものが必要だと思う。

└

そうだね、saplingとjjは確実に仲間だね :)

記事を読んでみたけど、jjの技術的なメリットは全然わからなかった。

└

うん、それが投稿の目的じゃなかったんだ。ただ、このスレッドにはそのことについてのコメントがいくつかあるよ。私の最初のコメントはこれだよ： https://news.ycombinator.com/item?id=45673808

└

著者の言葉を引用すると「Rustで書かれてるんだ！」ってことだね。これが全てだと思う。

本当にニュースなのは、何人かの人が「jjhub」みたいなものを作り始めたってことだと思う。 https://ersc.io/

└

「jjhub」は、まずまずの最初のアプローチだと思うし、これで話を始めることが多いかな。でも、ここで本当の価値を提供しないといけない。だって、もうjjをgithubと一緒に使えるし（実際、ずっと前から使ってる）、それだけじゃないからね。でも、そうだね :)

└

GitHubとその週ごとのダウンタイムから離れる理由がもう一つあるね！

└

これもあるよ: https://blog.tangled.org/stacking

└

Gerritはjjのコンセプトにすごくマッチしてるし、Jujutsuの変更IDをGerritに追加するためのRfCも受け入れられてるよ。

昨日、Jujutsuを試してみて、あなたのチュートリアルを見てたんだけど、すごく楽しかったし、可能性を感じたよ。でも、何か足りないピースがある気がする。例えば、PRレビューのためにGitHubにプッシュした場合、変更IDから何か得られるのかな？今のところ、Googleの内部Piperバックエンドの良い部分だけが恩恵を受けられる気がする。だから、ERSCでのアイデアや計画が気になる。でも、私が本当に求めているのは、分散型の非同期/オフラインファーストのコードレビューの流れが組み込まれていることなんだ。GitHubやその関連でのPRやMRで、gitの分散的な特性がなんか失われちゃった感じがする。

└

楽しんでもらえたみたいでよかった :) > PRレビューのためにGitHubにプッシュした場合、変更IDから何か得られるのかな？今のところ？あんまり。詳細はもっと複雑だけど、基本的には、あなたのプロジェクトがコメントやコミットの編集に関してGitHubの動作が気に入らない場合、新しいコミットを追加することを求められるから、その動作は変えられないんだ。でも、https://github.com/LucioFranco/jj-sprは、状況によってはその体験を提供してくれるかもしれない。もしあなたのプロジェクトがコミットの編集を許可しているなら、ローカルでは役立つよ。でも、面白い展開があって、GitHubの新しいSVPがjjが好きで、スタックされたdiffをGitHubに追加することに興味があるってツイートしたんだ。この「18ヶ月間新機能なし」っていうのとどう整合するのかは分からないけど、見てみよう！ > 私が本当に求めているのは、分散型の非同期/オフラインファーストのコードレビューの流れが組み込まれていることなんだ。これはコードレビューじゃなくて、イシュートラッキングなんだけど、今週はhttps://github.com/steveyegge/beadsを使ってみて、実際に楽しめる「リポジトリに問題を入れる」システムの最初のものかもしれないと思った。AI向けに作られてるって言ってるけど、AIを使わなくても大丈夫だよ。

Googleの全員がjjを使ってるとは言いたくないけど、その人数はかなり多いと思う。あの規模の会社で新しいVCSを導入するのがどれだけ大変かを考えるとね。Googleが気まぐれだとは言いたくないけど、GoogleのPerforceフォーク以外は数年ごとに廃止されるからね。昔はちゃんとしたgitラッパーがあったし、その後はmercurial+拡張、今はjjがmercurialの代わりになるはずで、これが7年くらいの間に起こったことだよね？

└

これにはPerforceフォークを廃止する意図もあると思う。まあ、確かに色々あったね。正直、外から見るのはもっと大変だよ！

└

これ、ちょっと違う気がするな。gitラッパーは完全にはサポートされてなかったし、いろいろと不具合もあったと思う（たぶん、20%くらいのプロジェクトだったし、すごく古いしね）。カスタマイズされたmercurialはもう7年以上使われてるし、もうすぐ10年になるんじゃないかな（今使ってるクライアントは7年目だし、最初のやつじゃないし）。

これめっちゃ楽しみ！去年ERSCの人たちと話したんだけど、ちょっと早すぎたんだよね。でも、彼らが作ってるものにはすごくワクワクしてるし、好きな人がそのプロジェクトに参加するのを見られて嬉しい。スティーブ、NYCに来たら連絡してね！

└

ありがとう！覚えておくようにするよ。

大きなバイナリファイルに対応してて、gitみたいに詰まったりしないの？確かにgitはウェブ開発では勝ってるけど、ゲーム開発みたいな業界ではPerforceが王様なんだよね… gitはバイナリファイルを扱えないからほとんど使われてない（大きなファイル拡張機能のことは知ってるけど、それじゃ足りないよ）。

└

今のところ特に何もないよ。でも、ここは知られてるエリアだから、何か起こるかもしれないね。様子を見よう。

└

Perforceのバイナリサポートは基本的にGit LFSと同じことをしてるよ。PerforceのバイナリサポートにはGit LFSにはない何かがあるの？私の知る限り、Perforceはすでに使われていて、企業向けのサポートもあるのが大きなポイントだね。

gitの知識を全く前提にしないjjのチュートリアルってある？gitなしでjjにどうアプローチするか見てみたいな。

└

そうでもないけど、あった方がいいと思う。