- 既存のDのリーダーシップを通じた貢献が長期にわたり滞っていたという不満が蓄積し、一部の貢献者が OpenD というD言語フォークへ移行
- 争点はDがクローズドソースかどうかというより、GPLでの公開やgdcのリリース後も、開発方式と意思決定がコミュニティに十分開かれていなかった点
- Ares/Tangoが後に druntime へつながった事例、Phobosの活動低下、PRの放置、「D gripes and wishes」後の実行不足が、フォークの根拠として挙げられている
- OpenDへの移行後、upstream DへのPR・バグレポート・ユーザー支援・DLF会議・DConf Onlineへの参加は停止され、dpldocs.infoは費用が賄える間は維持される
- 有料サポート契約のない既存のDライブラリとアプリケーションはupstream Dとの互換性保証を受けられず、長期サポートの道筋はOpenDへの参加側へ移る
OpenDへ移行した理由
- OpenD はD言語のフォークであり、既存のDリーダーシップを通じてupstreamへ貢献する過程が、かなり以前から非常にフラストレーションの大きいものだったという問題意識から始まった
- Dがクローズドソース言語だという繰り返し語られる主張は正確ではない
- コンパイラのD専用部分は2002年にGPLで公開された
- 全体がGPLのコンパイラであるgdcは2004年に公開された
- ただし、Dの開発方法論は十分にオープンではなく、意思決定においてコミュニティからの意味ある入力が非常に少なかったという批判が続いている
- Dの主要機能や概念、現存するDコードの相当部分はコミュニティからの意見と作業によって生まれたが、受け入れられた事例だけを見ると生存者バイアスに陥りかねない
古くからの貢献のボトルネックとAres/Tangoの事例
- Dの歴史には受け入れられたパッチも多いが、長期間放置されたパッチも多かった
- 現在 druntime として知られるコードは、Walterがコミュニティからの貢献を受け入れなかったことで生まれたフォークに端を発する
- 2004年、upstreamと協力しようとしていた開発者たちが、自分たちの貢献を失わないためにDをフォークした
- このフォークは当初 Ares と呼ばれ、その後ほかのコミュニティの取り組みと合流して Tango になった
- Tangoは「The Developer's Library for D」を自称し、開発者が実際に貢献を歓迎される場として機能した
- Tangoエコシステムには、Phobosエコシステムにはなかった多くの要素があった
- フォークが4年間維持され人気を得た後、upstreamが和解に動き、その流れが現在のdruntimeへつながった
- Ares/TangoフォークがなければDは市場で意味のある地位を得られなかったはずであり、このフォークがDを危機から救ったという判断が背景にある
黄金期以降に減った参加
- Tangoの中心開発者たちが戻り、Andrei Alexandrescuらが加わった時期は、D開発が比較的開かれており、2013年前後に活動が増えた黄金期として描かれている
- ほぼすべてのDの商用ユーザーが、Aresフォーク由来のコードに直接依存していた点も強調されている
- しかし従来の習慣は消えず、黄金期の貢献者の多くはコミュニティに残らなかった
- 一部は、自分の作業が評価されない壊れたプロセスを理由に、明示的に去った
- ほかの一部は個人的事情で活動が減り、新しい貢献者も十分には定着しなかった
- Phobosの開発活動は2018年半ばに大きく減少し、その後、小さな活動増加が2回あった
- berni44によるCTFE可能な浮動小数点フォーマットの追加
- Paul Backusのsumtypeモジュールが
std.sumtype として採用された事例
- berni44は2020年にPRレビューをほぼ3か月待った後、コミュニティを離れると述べ、1年後に戻って最近のPhobos開発活動の増加を生んだが、数か月後に再び去った
- dmd自体でもWalter個人の貢献量はおおむね一定だが、他の人々が減ったことで、その比率は黄金期の約1/6から現在の約1/3へ変わった
繰り返された不満の収集と実行不足
- 2022年のクリスマスごろ、Mike Parkerは人々に「D gripes and wishes」のリストを送ってほしいと依頼した
- 多くの人は結果は出ないだろうと見ていたが、回答は多かった
- 約6か月後の2023年5月18日、回答をまとめた公開文書が投稿された
- その後、公に確認された結果は次の目標設定にとどまった
- 言語・コンパイラ・標準ライブラリの安定化
- ツールとサードパーティライブラリのサポートなどのエコシステム改善
- Webサイトの整理、古いドキュメントとチュートリアルの更新、Webサイトの再設計などのコミュニティ強化
- 要請は「一般論ではなく具体的に書いてほしい」というものだったが、多くの具体的な不満への回答は、大きな分類の目標bulletにとどまった
- 2016H1 Vision Documentにも、参加拡大、ツール、言語の安定性と仕様改善、ライブラリ追加といった類似の目標があったため、目標設定よりも実行が必要だという立場である
OpenD移行で変わること
- upstream Dへの貢献の試みは停止され、コンパイラ全体を対象とするフォークである OpenD へ移行する
- dpldocs.infoのドキュメントホスティングはPatreonで費用がかろうじて賄われている状態で、費用が維持される限りdubパッケージのサポートを含めて運営を続ける
- upstream Dの更新は受け取らない
- 既存機能はおそらく引き続き正常に動作すると見ている
- ブログでのupstream D専用サポート部分は停止される
- 統計は今後含まれない
- 名称は「This Week in ARSD」に変わり、後に「This Week in OpenD」へ変わる可能性もある
- upstream DへのPRとバグレポートは即時停止される
- 本人に役立つ内容はupstreamへ送らず、OpenDへマージする
- Dユーザーへの支援も停止される
- 以前はさまざまな熟練度のDユーザーを毎週何時間も支援していたが、今後はupstream Dに関する質問への回答を保証しない
- 回答する場合は、OpenDを試すよう伝える可能性が高い
- DLF会議には、ガバナンス変更を事前条件として同意しない限り出席しない
- DConf Onlineのライブストリーム招待が来ても断る
- Dライブラリは、有料サポート契約がある対象に限り、内部バージョンと外部コンパイラ更新の間の互換性の約束を維持する
- それ以外のユーザーについては、upstream Dとの互換性は即時に取り消される
- コードはいかなる明示的・黙示的保証もなく、現状のまま提供される
- OpenDフォークに合流すれば、該当ライブラリのサポートは継続される
- Dアプリケーションもライブラリと同様にupstream Dとの互換性の約束はなく、もともと本人の用途向けに設計されているため互換性保証はより緩い
残る立場
- 過去16年間にDへ多くの時間を費やし、プログラミングのキャリアの大部分はDと、その前身であるDigital Mars C++のおかげだと述べている
- Walter Brightと同僚たちは人生に大きな影響を与え、Walterはプログラミング言語プロジェクトの優れた貢献者だと評価している
- それでも今はWalter BrightのDを離れ、OpenD という別の道を選ぶ
- OpenDが成功するにはやるべきことが多く、失敗する可能性も非常に高いが、今後その失敗の責任はOpenD側の自分たちだけにあると見ている
1件のコメント
Hacker News のコメント
少なくとも Walter と、おそらく他の D のリーダー層もここで活動しているので、これらのコメントを見る可能性は高い
彼らも人間であり、D を本当に大切に思っていて、私の経験では最善を尽くそうとしている基本的にはまともな人たちだ、ということを思い出してほしい
今回はなぜ違うと思えるのか分からないし、Tango パート2のように繰り返している感じがする
ただ、今回は船がもうずっと前に出てしまっているという違いがある
別のリーダーシップの下でプロジェクトがよりうまくいく可能性があるなら、その可能性は検討すべきだ
個人的には D が再び息を吹き返すことを本当に願っているし、今でも一番好きな言語だ
Walter や他の誰かを攻撃しようとしているのではなく、好きなものを生かそうとしている人たちにすぎない
残念だが、こういうことはいずれ起きるしかなかった。何年もの間、D のフォークの話があまりにも多く出ていたからだ
2010年に Andrei Alexandrescu の本が出た頃、D の良かった点のほぼすべてが C#、Java、C++ に取り込まれた
実装は D ほどすっきりしていないかもしれないが、より良いツールやライブラリエコシステムの中で何らかの形で使えるなら、その差はそれほど重要ではない
人を引きつける目玉機能を追いかけるのにあまりにも多くの時間を失い、その機能群を安定化させることもできなかった
Andrei も最近は D より C++ と CUDA の方で忙しいようだ
この10年でネイティブにコンパイルされるプログラミング言語のルネサンスまで重なり、競争はさらに激しくなった
だからこそ余計に惜しい。コミュニティ自体には、話していて楽しい優れた人たちが多いからだ
毎日 Python を使っているが、D の恋しい点は多い
性能は言うまでもない
外部の人間として D を眺めていたとき、似たようなことを見た
Rust が新しかった頃、**ライフタイム（lifetime）**の概念が D コミュニティに提案されたが、Walter は不要だと考えた
数年後、Walter が Rust とは十分に異なる独自のライフタイム提案を持ち込み、そのためコミュニティの以前の提案よりも検証が少ない状態だった
いまは D への関心を失っているので、新しいライフタイム機能がどれほど成熟したのかは分からないが、Rust ほど有用なら驚くだろう
どんな機能にも、他の言語機能との相互作用、認知負荷、コンパイル速度の低下、標準ライブラリ設計の複雑化、後方互換性の破壊といったトレードオフがある
他の言語で気に入っている機能を1つサポートするために、大規模な改修を期待するのは合理的ではないと思う
私の研究グループは数年前、反応の乏しさと良くない言語開発の方向性が原因で D を離れ、Rust に移った
Adam たちが OpenD で成功することを願っているが、この機会にもっと独特で記憶に残る名前を選ぶとよいと思う
新しい ガバナンスモデルは、新機能の一覧を宣言したり一部を外すと決めたりすることから始まるのではなく、関心のある当事者の定足数でガバナンスを議論するところから始まる
それはモデルの変化ではなく、単なる政権交代だ
正当な不満はあり得るし、D が Walter を門番として頼るやり方は、ある人にとっては厳格すぎるかもしれない
しかし、このフォークの始まり方は長期的には良い兆候ではない
フォークが成功するには幅広い支持を得る必要があり、最終的には数は少ないが多作な貢献者数人だけでなく、D コミュニティの過半に近い人々を連れてくる必要がある
そうでなければフォークも失敗し、元のプロジェクトへの関心もさらに分断され、残っていた生存可能性まで失いかねない
また、何十年にもわたって支援する能力と意志が必要だ
更新が上がったようだ: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... そしてある程度の関心も集めたらしい
個人的には、名前を Died にしていたらもっと面白かったと思う
“It never Died” のような格好いいフレーズも可能だし、フォークであることも示せるうえ、後で必要なら言語を新しい方向へ持っていく余地も生まれる
OpenD は完全互換のような印象を与える
もちろん私はこの件に直接の利害関係はなく、うまくいってほしいと思っている
D フォーラムにこの話題の大きなスレッドがある: https://forum.dlang.org/thread/beykokfitddfdsjyqjjy@forum.dl...
元の記事は人物間の対立への不満が主だが、このリンクには技術的な議論がより多い
これを見ると、フォークしている人たちは実質的に別の言語を望んでおり、そのために複数の 互換性を壊す変更も受け入れるつもりのようだ
個人的には、D がガベージコレクターに全面的に注力するなら、どんなニッチ市場を狙っているのか混乱する
以前から明確なニッチがあったわけでもない。本質的には「10% より良い C++」で、はっきり差別化できるキラー機能がなく、売り込みにくかった
たいていは既存のサポート、コードベース、産業基盤のために C++ に残るか、新規プロジェクトには Rust を使うか、シンプルさを求めるなら Zig を使う可能性が高い
特に C++20 以降は、すでに「10% より良い C++」が存在しているようなもの
とはいえ、ガベージコレクターに注力することが大きな助けになるのかも分からない
そうなると C# や Java と競合することになるが、この 2 つは最初からガベージコレクションがあり、安全で簡潔な C++ の後継として意図された言語であり、現時点でこれらとどう競争できるのかはよく見えない
特に C# は、生ポインタ、参照型/値型の制御、メモリレイアウト制御といったかなり優れた低レベル・unsafe 機能に加え、年季の入ったオブジェクト指向優先言語としては悪くない型システムとリフレクション、さらに ML 系の機能を継続的に取り入れている
正直、D のビジョンはいつも混乱しているように見えた
BetterC、safe モード、ライフタイムのような特定の言語機能の文書を読んでみたが、構文的に読みづらく、細かな説明は多いものの、全体としてうまく説明されていなかった
言語としての一貫した設計ビジョンや目的をきちんと感じられなかった
投稿者はこの問題に触れてはいるが、彼らのビジョンも特に明確になったようには見えない
いくつか具体的な中期的技術目標があるのは良いが、その目標が何のためにあるのかがはっきりしない
私は Rust プログラマーなので、新しい個人プロジェクトに何を使うかは明らかだが、別のものを選ばなければならないなら、むしろ OCaml、C++、さらには C# を使うと思う
第一に、D は C++ の代替ではあるが C++ ではなく、多くの C++ 開発者がその違いにいら立った
第二に、D は C++ の代替以上にはるかに多くのことができる
スクリプト、汎用プログラミング言語、特に ImportC や BetterC のような C 相互運用性に使える
フォークの目標の一つは、ガベージコレクターについてもはや言い訳しないこと
標準ライブラリには今でも参照カウント、unique pointer などもある
誰かがガベージコレクターを避ける関数を貢献しようとするなら、受け入れられると思う
ただしこのフォークでは、Adam が標準ライブラリに新しい関数を入れるとき、ガベージコレクターを避けようと過度に苦心する姿はあまり見られない可能性が高い
彼はガベージコレクターへの恐怖は誇張されていると考えている
この 10 年で、プログラミング言語のガバナンスをめぐって学ぶべきことが多かった
台頭しつつ変化している言語を見ると、それらもガバナンスに関して大きな衝突や失敗を経験している
今では、プログラミング言語を見るときに核心として注目すべきなのはガバナンスだと思う
彼らが運営方法をどう語っているか、実際にはどうしているか、これまでの結果はどうだったか、今後どうなりそうかを見る必要がある
プログラミング言語の進化はほとんど複雑性管理に近く、同時に複数の利害関係者の要求をバランスよく満たさなければならない
ほぼすべてのガバナンス上の対立は、ある利害関係者集団が別の集団にとって不可欠な要件に不満を示すことで生じており、常に両方を満足させることはできない
Rust の
asyncはその事例として知られており、動作はするものの全体として満足のいかない設計を説明しているGo は珍しい例外で、コアチームにはすべての利害関係者を尊重しなければならない理由がなく、そうするためのリソースと意志も十分にあったが、それでも一部の対立は起きた
1960〜80 年代の標準策定モデルの方がはるかに優れており、政治的な争いも短い期間に限定していた
複数のコンパイラ実装が存在することに、どんな否定的な面があるのかよく分からない
個人的には、それこそが C があれほど広く普及した主な理由だと思う
コンパイラがそれぞれ別の方向を探索でき、価値が証明された言語拡張は最終的に他の実装にも採用され、ときには委員会の合意形成の過程で過度に損なわれないまま標準に入ることもある
少なくとも gcc と dlang 側の実装で 2 つはあると思っていた