- Khi những bất mãn về việc đóng góp thông qua ban lãnh đạo D hiện tại bị chặn trong thời gian dài tích tụ, một số người đóng góp đã chuyển sang OpenD, một nhánh fork của ngôn ngữ D
- Vấn đề cốt lõi không phải là D có phải mã nguồn đóng hay không, mà là ngay cả sau khi mã GPL được công khai và gdc được phát hành, phương thức phát triển và ra quyết định vẫn chưa đủ cởi mở với cộng đồng
- Trường hợp Ares/Tango sau này dẫn tới druntime, sự suy giảm hoạt động của Phobos, PR bị bỏ ngỏ, và việc thiếu hành động sau “D gripes and wishes” được nêu ra như cơ sở cho việc fork
- Sau khi chuyển sang OpenD, việc gửi PR, báo lỗi, hỗ trợ người dùng, tham gia họp DLF và tham gia DConf Online cho upstream D sẽ dừng lại; dpldocs.info sẽ được duy trì chừng nào còn đủ chi phí chi trả
- Các thư viện và ứng dụng D hiện có không có hợp đồng hỗ trợ trả phí sẽ không còn được đảm bảo tương thích với upstream D, và lộ trình hỗ trợ dài hạn sẽ chuyển sang phía tham gia OpenD
Lý do chuyển sang OpenD
- OpenD là một nhánh fork của ngôn ngữ D, xuất phát từ nhận thức rằng quá trình đóng góp lên upstream thông qua ban lãnh đạo D hiện tại từ lâu đã rất gây thất vọng
- Câu nói lặp đi lặp lại rằng D là một ngôn ngữ mã nguồn đóng là không chính xác
- Phần dành riêng cho D trong trình biên dịch đã được công khai theo GPL vào năm 2002
- gdc, một trình biên dịch GPL hoàn chỉnh, đã được công khai vào năm 2004
- Tuy nhiên, phương pháp phát triển của D chưa đủ cởi mở, và các chỉ trích về việc cộng đồng có quá ít tiếng nói có ý nghĩa trong quá trình ra quyết định vẫn tiếp diễn
- Các tính năng và khái niệm cốt lõi của D, cùng với một phần đáng kể mã D hiện có, đều đến từ ý kiến đầu vào và công sức của cộng đồng; nhưng nếu chỉ nhìn vào những trường hợp được chấp nhận thì rất dễ rơi vào thiên kiến sống sót
Nút thắt đóng góp kéo dài và trường hợp Ares/Tango
- Trong lịch sử D có nhiều bản vá đã được chấp nhận, nhưng cũng có không ít bản vá bị bỏ mặc trong thời gian dài
- Phần mã hiện được biết đến với tên druntime bắt đầu từ một nhánh fork xuất hiện do Walter không chấp nhận đóng góp từ cộng đồng
- Năm 2004, các lập trình viên muốn hợp tác với upstream đã fork D để không làm mất các đóng góp của mình
- Nhánh fork này ban đầu được gọi là Ares, sau đó hợp nhất với các nỗ lực khác của cộng đồng để trở thành Tango
- Tango tự nhận là “The Developer's Library for D”, và thực sự hoạt động như một không gian nơi các lập trình viên được chào đón đóng góp
- Hệ sinh thái Tango có nhiều yếu tố mà hệ sinh thái Phobos không có
- Sau khi nhánh fork này được duy trì suốt 4 năm và trở nên phổ biến, upstream bắt đầu hòa giải, và dòng chảy đó dẫn tới druntime ngày nay
- Đằng sau lập luận này là nhận định rằng nếu không có nhánh fork Ares/Tango thì D đã không thể có được vị thế đáng kể trên thị trường, và chính nhánh fork này đã cứu D khỏi khủng hoảng
Sự tham gia suy giảm sau thời kỳ hoàng kim
- Giai đoạn các nhà phát triển cốt lõi của Tango quay lại và Andrei Alexandrescu cùng những người khác tham gia được mô tả là thời kỳ phát triển D tương đối cởi mở, một thời kỳ hoàng kim khi hoạt động tăng mạnh vào khoảng năm 2013
- Cũng nhấn mạnh rằng gần như mọi người dùng D trong môi trường thương mại đều trực tiếp phụ thuộc vào mã xuất phát từ nhánh fork Ares
- Tuy nhiên, các thói quen cũ không biến mất, và phần lớn những người đóng góp trong thời kỳ hoàng kim đã không ở lại với cộng đồng
- Một số người ra đi một cách công khai với lý do là quy trình bị hỏng, trong đó công sức của họ không được coi trọng
- Một số khác giảm hoạt động vì lý do cá nhân, và không có đủ người đóng góp mới ở lại
- Hoạt động phát triển Phobos giảm mạnh vào giữa năm 2018, sau đó chỉ có hai đợt tăng nhỏ
- berni44 bổ sung khả năng định dạng số thực dấu chấm động có thể CTFE
- Mô-đun sumtype của Paul Backus được tiếp nhận thành
std.sumtype
- berni44 cho biết sẽ rời cộng đồng sau khi chờ gần 3 tháng mà PR không được review trong năm 2020; một năm sau người này quay lại và tạo ra đợt tăng hoạt động phát triển Phobos gần đây, nhưng vài tháng sau lại rời đi
- Ngay cả trong dmd, lượng đóng góp cá nhân của Walter nhìn chung vẫn ổn định, nhưng khi đóng góp từ người khác giảm xuống thì tỷ trọng của ông đã tăng từ khoảng 1/6 trong thời kỳ hoàng kim lên khoảng 1/3 hiện nay
Việc thu thập phàn nàn lặp lại và thiếu hành động
- Vào khoảng Giáng sinh năm 2022, Mike Parker đã đề nghị mọi người gửi danh sách “D gripes and wishes”
- Nhiều người cho rằng sẽ không có kết quả gì, nhưng số phản hồi vẫn rất nhiều
- Khoảng 6 tháng sau, vào ngày 18/5/2023, một tài liệu công khai tổng hợp phản hồi đã được đăng
- Sau đó, kết quả được xác nhận công khai chỉ dừng ở việc đặt ra các mục tiêu sau
- ổn định ngôn ngữ, trình biên dịch và thư viện chuẩn
- cải thiện hệ sinh thái như hỗ trợ công cụ và thư viện bên thứ ba
- củng cố cộng đồng như dọn dẹp website, cập nhật tài liệu và tutorial cũ, tái thiết kế website
- Yêu cầu ban đầu là “đừng viết chung chung mà hãy viết cụ thể”, nhưng câu trả lời cho nhiều phàn nàn cụ thể cuối cùng vẫn chỉ dừng ở các gạch đầu dòng mục tiêu rất rộng
- Vì Vision Document 2016H1 cũng từng có những mục tiêu tương tự như mở rộng sự tham gia, công cụ, cải thiện độ ổn định ngôn ngữ và đặc tả, cũng như bổ sung thư viện, nên quan điểm ở đây là điều cần thiết không phải đặt mục tiêu mà là thực thi
Điều gì thay đổi khi chuyển sang OpenD
- Các nỗ lực đóng góp cho upstream D sẽ dừng lại và chuyển sang OpenD, một nhánh fork nhắm tới toàn bộ trình biên dịch
- Dịch vụ lưu trữ tài liệu dpldocs.info hiện chỉ vừa đủ chi trả nhờ Patreon, và sẽ tiếp tục hoạt động, bao gồm hỗ trợ gói dub, miễn là còn duy trì được chi phí
- Sẽ không nhận cập nhật từ upstream D
- Các tính năng hiện có có lẽ vẫn sẽ tiếp tục hoạt động tốt
- Phần hỗ trợ dành riêng cho upstream D trên blog sẽ bị dừng
- Sẽ không còn bao gồm số liệu thống kê
- Tên sẽ đổi thành “This Week in ARSD”, và sau này có thể đổi thành “This Week in OpenD”
- PR và báo lỗi cho upstream D sẽ dừng ngay lập tức
- Những gì hữu ích cho bản thân sẽ không gửi lên upstream mà được merge vào OpenD
- Việc hỗ trợ người dùng D cũng sẽ dừng
- Trước đây tác giả đã dành vài giờ mỗi tuần để hỗ trợ người dùng D ở nhiều mức độ thành thạo khác nhau, nhưng giờ sẽ không còn đảm bảo trả lời câu hỏi về upstream D
- Nếu có trả lời, rất có thể sẽ khuyên họ thử OpenD
- Sẽ không tham dự các cuộc họp DLF trừ khi đồng ý về thay đổi quản trị như một điều kiện tiên quyết
- Nếu có lời mời tham gia livestream DConf Online thì cũng sẽ từ chối
- Với các thư viện D, cam kết tương thích giữa phiên bản nội bộ và cập nhật trình biên dịch bên ngoài chỉ được duy trì cho các đối tượng có hợp đồng hỗ trợ trả phí
- Với những người dùng khác, khả năng tương thích với upstream D sẽ bị hủy ngay lập tức
- Mã được cung cấp nguyên trạng, không có bất kỳ bảo đảm rõ ràng hay ngầm định nào
- Nếu tham gia nhánh fork OpenD thì hỗ trợ cho các thư viện đó sẽ tiếp tục
- Các ứng dụng D cũng giống như thư viện, không còn cam kết tương thích với upstream D; vốn dĩ chúng được thiết kế cho nhu cầu riêng của tác giả nên bảo đảm tương thích càng lỏng hơn
Lập trường còn lại
- Tác giả cho biết trong 16 năm qua đã dành rất nhiều thời gian cho D, và phần lớn sự nghiệp lập trình của mình có được là nhờ D và trước đó là Digital Mars C++
- Walter Bright và các cộng sự đã có ảnh hưởng lớn đến cuộc đời tác giả, và Walter được đánh giá là một người đóng góp xuất sắc cho các dự án ngôn ngữ lập trình
- Dù vậy, giờ đây tác giả sẽ rời D của Walter Bright để chọn một con đường riêng mang tên OpenD
- Để OpenD thành công còn rất nhiều việc phải làm và khả năng thất bại cũng rất cao, nhưng từ giờ trách nhiệm cho thất bại đó được xem là chỉ thuộc về chính phía OpenD
1 bình luận
Ý kiến trên Hacker News
Ít nhất Walter và có lẽ cả những người khác trong ban lãnh đạo D cũng hoạt động ở đây, nên rất có khả năng họ sẽ thấy các bình luận này
Mong mọi người nhớ rằng họ cũng là con người, thật sự quan tâm đến D, và theo trải nghiệm của tôi thì về cơ bản họ là những người tử tế đang cố gắng làm hết sức mình
Tôi không hiểu vì sao lần này lại được cho là sẽ khác, cảm giác như phần 2 của Tango lặp lại vậy
Chỉ khác là giờ con thuyền đã rời bến từ rất lâu rồi
Nếu dự án có thể tốt hơn dưới một ban lãnh đạo khác thì khả năng đó nên được xem xét
Cá nhân tôi thật sự hy vọng D có thể sống lại, vì đây vẫn là ngôn ngữ tôi thích nhất từ trước đến nay
Đây không phải là để công kích Walter hay bất kỳ ai khác, mà chỉ là những người đang cố cứu thứ họ yêu thích
Đáng tiếc nhưng chuyện này sớm muộn cũng phải xảy ra. Đã có quá nhiều lời bàn về một fork của D trong nhiều năm qua
Khi cuốn sách của Andrei Alexandrescu ra mắt vào năm 2010, gần như mọi điểm hay của D đều đã được đưa vào C#, Java và C++
Cách triển khai có thể không gọn gàng bằng D, nhưng nếu có thể dùng chúng dưới hình thức nào đó trong một hệ sinh thái công cụ và thư viện tốt hơn thì khác biệt ấy không còn quá quan trọng
Đã mất quá nhiều thời gian để chạy theo những tính năng vàng nhằm thu hút người dùng, mà lại còn không ổn định hóa được các tính năng đó
Dạo này Andrei dường như cũng bận với C++ và CUDA hơn là D
Thêm vào đó, 10 năm qua còn chứng kiến thời kỳ phục hưng của các ngôn ngữ lập trình biên dịch native, nên cạnh tranh càng gay gắt hơn
Vì thế lại càng đáng tiếc hơn, vì bản thân cộng đồng có rất nhiều người tuyệt vời để trò chuyện
Tôi dùng Python mỗi ngày, nhưng có nhiều thứ ở D mà tôi nhớ
Chưa kể đến hiệu năng
Với tư cách người ngoài đang tìm hiểu D, tôi từng thấy một việc tương tự
Khi Rust còn mới, khái niệm lifetime đã được đề xuất với cộng đồng D nhưng Walter cho rằng nó không cần thiết
Vài năm sau, Walter mang đến một đề xuất lifetime của riêng mình đủ khác với Rust, nên vì thế nó cũng kém được kiểm chứng hơn so với các đề xuất trước đó từ cộng đồng
Giờ tôi đã mất hứng thú với D nên không rõ tính năng lifetime mới đã trưởng thành đến đâu, nhưng nếu nó hữu ích ngang Rust thì chắc tôi sẽ ngạc nhiên
Bất kỳ tính năng nào cũng có những đánh đổi như tương tác với các tính năng ngôn ngữ khác, gánh nặng nhận thức, tốc độ biên dịch chậm đi, độ phức tạp trong thiết kế thư viện chuẩn, hay phá vỡ tương thích ngược
Tôi không nghĩ việc kỳ vọng một cuộc đại tu quy mô lớn chỉ để hỗ trợ một tính năng mà bạn thích từ ngôn ngữ khác là hợp lý
Nhóm nghiên cứu của tôi đã rời D để sang Rust vài năm trước vì thiếu phản hồi và định hướng phát triển ngôn ngữ không tốt
Tôi hy vọng Adam và những người khác sẽ thành công với OpenD, nhưng nhân dịp này sẽ tốt hơn nếu chọn một cái tên độc đáo và dễ nhớ hơn
Mô hình quản trị mới không bắt đầu bằng việc công bố danh sách tính năng mới hay quyết định loại bỏ một số thứ, mà lại bắt đầu bằng việc thảo luận quản trị với một nhóm đủ số lượng các bên quan tâm
Đó không phải là thay đổi mô hình, mà chỉ là thay đổi người cầm quyền
Có thể có những bất mãn chính đáng, và cách D phụ thuộc vào Walter như một người gác cổng có thể quá cứng nhắc với một số người
Nhưng cách cái fork này được khởi động không phải là tín hiệu tốt về lâu dài
Muốn fork thành công thì phải có được sự ủng hộ rộng rãi, và cuối cùng phải kéo được gần như đa số cộng đồng D chứ không chỉ một vài người đóng góp năng suất cao nhưng số lượng ít
Nếu không, cả fork cũng thất bại, còn sự chú ý dành cho bản gốc lại tiếp tục bị chia nhỏ, làm mất nốt khả năng tồn tại vốn đã ít ỏi
Ngoài ra còn cần năng lực và ý chí để duy trì hỗ trợ trong hàng chục năm
Có vẻ đã có cập nhật: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... và hình như cũng thu hút được một mức độ quan tâm nhất định
Cá nhân tôi thấy nếu đặt tên là Died thì sẽ vui hơn
Có thể dùng những câu kiểu “It never Died”, vừa ngầu, vừa thể hiện đây là một fork, lại còn mở ra khả năng đưa ngôn ngữ theo hướng mới sau này nếu cần
OpenD tạo cảm giác như là tương thích hoàn toàn
Dù sao thì tôi cũng không có lợi ích trực tiếp gì ở đây, nhưng chúc mọi chuyện thuận lợi
Có một luồng thảo luận lớn về chủ đề này trên diễn đàn D: https://forum.dlang.org/thread/beykokfitddfdsjyqjjy@forum.dl...
Bài gốc chủ yếu là than phiền về xung đột giữa các cá nhân, còn liên kết này có nhiều thảo luận kỹ thuật hơn
Đọc nội dung này thì có vẻ những người đi fork thực ra muốn một ngôn ngữ khác, và vì điều đó họ cũng sẵn sàng chấp nhận nhiều thay đổi phá vỡ tương thích
Cá nhân tôi thấy khá khó hiểu nếu D tập trung toàn diện vào garbage collector thì rốt cuộc nó đang nhắm tới thị trường ngách nào
Trước đây cũng không hẳn đã có một thị trường ngách rõ ràng. Về bản chất, nó là “C++ tốt hơn 10%”, nhưng lại không có tính năng sát thủ nào thực sự khác biệt nên rất khó thuyết phục người khác dùng
Phần lớn mọi người có lẽ sẽ ở lại với C++ vì hỗ trợ sẵn có, codebase hiện hữu và nền tảng trong ngành, hoặc dùng Rust cho dự án mới, hay chọn Zig nếu muốn sự đơn giản
Đặc biệt là sau C++20 thì coi như đã có sẵn một thứ “C++ tốt hơn 10%” rồi
Tôi cũng không rõ việc tập trung vào garbage collector có giúp ích được bao nhiêu
Làm vậy thì sẽ phải cạnh tranh với C# và Java, mà cả hai đều là những ngôn ngữ ngay từ đầu đã có garbage collection, an toàn và được định hướng là hậu duệ súc tích của C++, nên ở thời điểm này tôi không thấy rõ D có thể cạnh tranh với chúng như thế nào
Đặc biệt, C# có khá nhiều tính năng mức thấp và
unsaferất tốt như con trỏ thô, kiểm soát reference type/value type, kiểm soát bố cục bộ nhớ; ngoài ra với tư cách là một ngôn ngữ ưu tiên hướng đối tượng đã có tuổi, nó vẫn có hệ thống kiểu khá ổn, reflection, và tiếp tục tiếp nhận các tính năng từ họ MLThành thật mà nói, tầm nhìn của D từ trước đến nay luôn khá mơ hồ
Tôi đã đọc tài liệu về một số tính năng ngôn ngữ cụ thể như BetterC, chế độ safe, lifetime, nhưng cú pháp thì khó đọc, và dù có nhiều chi tiết giải thích, nhìn chung vẫn không được trình bày tốt
Tôi không thực sự cảm nhận được một tầm nhìn thiết kế nhất quán hay mục đích rõ ràng của ngôn ngữ
Tác giả có nhắc đến vấn đề này, nhưng tầm nhìn của họ cũng không có vẻ rõ ràng hơn bao nhiêu
Có một vài mục tiêu kỹ thuật cụ thể trong trung hạn thì tốt, nhưng vẫn chưa rõ những mục tiêu đó tồn tại để phục vụ điều gì
Tôi là một lập trình viên Rust nên chuyện sẽ dùng gì cho dự án cá nhân mới thì quá rõ, nhưng nếu phải chọn thứ khác thì tôi thà dùng OCaml, C++, thậm chí cả C#
Thứ nhất, D là một lựa chọn thay thế cho C++, nhưng nó không phải C++, và nhiều lập trình viên C++ đã thất vọng vì sự khác biệt đó
Thứ hai, D có thể làm được nhiều thứ hơn rất nhiều so với chỉ là một lựa chọn thay thế C++
Nó có thể dùng cho scripting, như một ngôn ngữ lập trình đa dụng, và đặc biệt cho khả năng tương tác với C như ImportC và BetterC
Một trong các mục tiêu của bản fork này là không tiếp tục phải xin lỗi vì garbage collector nữa
Thư viện chuẩn vẫn có cả reference counting, unique pointer và những thứ tương tự
Nếu ai đó muốn đóng góp các hàm tránh dùng garbage collector thì tôi nghĩ vẫn sẽ được chấp nhận
Chỉ là trong bản fork này, có lẽ sẽ khó thấy Adam cố gắng quá mức để tránh garbage collector khi thêm hàm mới vào thư viện chuẩn
Anh ấy tin rằng nỗi sợ garbage collector đã bị phóng đại
Trong 10 năm qua đã có rất nhiều điều để học về governance của ngôn ngữ lập trình
Khi nhìn vào các ngôn ngữ mới nổi và đang thay đổi, có thể thấy họ cũng đã trải qua những va chạm lớn hoặc sai lầm liên quan đến governance
Giờ đây, khi nhìn vào một ngôn ngữ lập trình, tôi nghĩ yếu tố cốt lõi cần xem xét chính là governance
Cần nhìn vào cách họ nói về phương thức vận hành, cách họ thực sự làm, kết quả từ trước đến nay ra sao, và có vẻ sau này sẽ đi theo hướng nào
Sự tiến hóa của ngôn ngữ lập trình gần như là bài toán quản lý độ phức tạp, đồng thời phải cân bằng nhu cầu của nhiều bên liên quan khác nhau
Gần như mọi xung đột về governance đều phát sinh khi một nhóm bên liên quan phàn nàn về những yêu cầu vốn là thiết yếu đối với nhóm khác, và không phải lúc nào cũng có thể làm hài lòng cả hai bên
asynccủa Rust là một ví dụ điển hình: nó hoạt động được, nhưng lại minh họa cho một thiết kế nhìn chung không thật sự thỏa đángGo là ngoại lệ hiếm hoi, vì nhóm nòng cốt không có lý do gì phải chiều theo mọi bên liên quan, đồng thời cũng có đủ nguồn lực và ý chí để làm vậy, nhưng ngay cả thế vẫn có một số xung đột xảy ra
Mô hình xây dựng tiêu chuẩn của giai đoạn 1960~80 tốt hơn nhiều, và cũng giới hạn các cuộc đấu đá chính trị trong một khoảng thời gian ngắn hơn
Tôi không thực sự thấy có mặt tiêu cực gì từ việc tồn tại nhiều triển khai compiler
Cá nhân tôi cho rằng đó là lý do chính khiến C trở nên phổ biến đến vậy
Các compiler có thể tự khám phá những hướng đi khác nhau, và các phần mở rộng ngôn ngữ đã chứng minh được giá trị cuối cùng sẽ được các triển khai khác tiếp nhận, đôi khi thậm chí còn đi vào tiêu chuẩn mà không bị làm méo mó quá nhiều bởi quá trình đồng thuận của ủy ban
Ít nhất tôi nghĩ là đã có 2 cái, một từ phía gcc và một từ phía dlang rồi chứ