OpenD ฟอร์กของภาษา D ที่ยินดีต้อนรับการมีส่วนร่วมจากทุกคน
(dpldocs.info)- หลังจากความไม่พอใจสะสมมานานว่าการมีส่วนร่วมผ่านผู้นำ D เดิมถูกปิดกั้นเป็นเวลานาน ผู้มีส่วนร่วมบางส่วนจึงย้ายไปยังฟอร์กของภาษา D ชื่อ OpenD
- ประเด็นไม่ได้อยู่ที่ว่า D เป็นโอเพนซอร์สหรือไม่เท่าใดนัก แต่อยู่ที่ว่าแม้หลังจากเปิด GPL และปล่อย gdc แล้ว วิธีการพัฒนาและการตัดสินใจ ก็ยังไม่ได้เปิดให้ชุมชนมีส่วนร่วมมากพอ
- มีการยกกรณี Ares/Tango ที่ต่อมากลายเป็น druntime, กิจกรรมของ Phobos ที่ลดลง, PR ที่ถูกปล่อยค้าง และการขาดการลงมือทำหลัง “D gripes and wishes” เป็นเหตุผลของการฟอร์ก
- หลังย้ายไป OpenD จะหยุด PR, รายงานบั๊ก, การสนับสนุนผู้ใช้, การเข้าร่วมประชุม DLF และการเข้าร่วม DConf Online สำหรับ upstream D ส่วน dpldocs.info จะยังคงดูแลตราบใดที่ค่าใช้จ่ายยังครอบคลุมได้
- ไลบรารีและแอปพลิเคชัน D เดิมที่ไม่มีสัญญาสนับสนุนแบบชำระเงินจะไม่ได้รับการรับประกันความเข้ากันได้กับ upstream D และเส้นทางการสนับสนุนระยะยาวจะย้ายไปทางการเข้าร่วม OpenD
เหตุผลที่ย้ายไป OpenD
- OpenD เป็นฟอร์กของภาษา D และเริ่มจากการตระหนักว่ากระบวนการมีส่วนร่วมกับ upstream ผ่านผู้นำ D เดิมนั้นสร้างความผิดหวังอย่างมากมานานแล้ว
- คำกล่าวซ้ำ ๆ ว่า D เป็น ภาษาซอร์สปิด นั้นไม่ถูกต้อง
- ส่วนเฉพาะของคอมไพเลอร์สำหรับ D ถูกเปิดเป็น GPL ในปี 2002
- gdc ซึ่งเป็นคอมไพเลอร์ GPL ทั้งหมด ถูกเผยแพร่ในปี 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 และหลังจากนั้นมีกิจกรรมเพิ่มขึ้นเล็กน้อยสองครั้ง
- การเพิ่มการจัดรูปแบบเลขทศนิยมที่ใช้ CTFE ได้ของ berni44
- กรณีที่โมดูล sumtype ของ Paul Backus ได้รับการรับเข้าเป็น
std.sumtype
- berni44 กล่าวในปี 2020 ว่าจะออกจากชุมชน หลังรอรีวิว PR เกือบ 3 เดือน และกลับมาอีกครั้งหลังจากนั้น 1 ปีจนทำให้กิจกรรมพัฒนา Phobos เพิ่มขึ้นเมื่อเร็ว ๆ นี้ แต่ก็จากไปอีกครั้งไม่กี่เดือนต่อมา
- ใน dmd เอง ปริมาณการมีส่วนร่วมส่วนตัวของ Walter โดยรวมค่อนข้างคงที่ แต่เมื่อคนอื่นลดลง สัดส่วนจึงเปลี่ยนจากประมาณ 1/6 ในยุคทองเป็นประมาณ 1/3 ในปัจจุบัน
การรวบรวมข้อร้องเรียนซ้ำ ๆ และการลงมือทำที่ไม่เพียงพอ
- ราวช่วงคริสต์มาสปี 2022 Mike Parker ขอให้ผู้คนส่งรายการ “D gripes and wishes” มาให้
- หลายคนคิดว่าจะไม่มีผลลัพธ์ แต่ก็มีการตอบกลับจำนวนมาก
- ประมาณ 6 เดือนต่อมา คือวันที่ 18 พฤษภาคม 2023 มีการเผยแพร่เอกสารสาธารณะที่รวบรวมคำตอบ
- ผลลัพธ์ที่ยืนยันได้ต่อสาธารณะหลังจากนั้นมีเพียงการตั้งเป้าหมายต่อไปนี้
- ทำให้ภาษา คอมไพเลอร์ และไลบรารีมาตรฐานมีเสถียรภาพ
- ปรับปรุงระบบนิเวศ เช่น เครื่องมือและการสนับสนุนไลบรารีของบุคคลที่สาม
- เสริมความแข็งแรงของชุมชน เช่น จัดระเบียบเว็บไซต์ อัปเดตเอกสารและบทเรียนเก่า และออกแบบเว็บไซต์ใหม่
- แม้คำขอคือ “อย่าเขียนแบบทั่วไป ให้เขียนอย่างเฉพาะเจาะจง” แต่คำตอบต่อข้อร้องเรียนเฉพาะจำนวนมากกลับหยุดอยู่ที่ bullet เป้าหมายหมวดใหญ่
- เนื่องจาก 2016H1 Vision Document ก็มีเป้าหมายคล้ายกัน เช่น การขยายการมีส่วนร่วม เครื่องมือ เสถียรภาพและการปรับปรุงสเปกของภาษา และการเพิ่มไลบรารี จึงมีจุดยืนว่าจำเป็นต้องมี การลงมือทำ มากกว่าการตั้งเป้าหมาย
สิ่งที่จะเปลี่ยนไปเมื่อย้ายไป OpenD
- จะหยุดความพยายามมีส่วนร่วมกับ upstream D และย้ายไปยัง OpenD ซึ่งเป็นฟอร์กที่ครอบคลุมคอมไพเลอร์ทั้งหมด
- โฮสติ้งเอกสาร dpldocs.info อยู่ในสถานะที่ Patreon พอครอบคลุมค่าใช้จ่ายอย่างหวุดหวิด และจะดำเนินต่อไป รวมถึงการรองรับแพ็กเกจ dub ตราบใดที่ยังรักษาค่าใช้จ่ายได้
- จะไม่รับอัปเดตจาก upstream D
- คาดว่าฟังก์ชันเดิมน่าจะยังทำงานได้ดีต่อไป
- ส่วนสนับสนุนเฉพาะ upstream D ในบล็อกจะหยุดลง
- จะไม่มีการรวมสถิติอีกต่อไป
- ชื่อจะเปลี่ยนเป็น “This Week in ARSD” และอาจเปลี่ยนเป็น “This Week in OpenD” ในภายหลัง
- PR และรายงานบั๊กต่อ upstream D จะหยุดทันที
- สิ่งที่เป็นประโยชน์ต่อตนเองจะไม่ส่งไป upstream แต่จะ merge เข้า OpenD
- การสนับสนุนผู้ใช้ D ก็จะหยุดเช่นกัน
- ในอดีตเคยสนับสนุนผู้ใช้ D หลายระดับทักษะหลายชั่วโมงต่อสัปดาห์ แต่จากนี้จะไม่รับประกันว่าจะตอบคำถามเกี่ยวกับ upstream D
- หากตอบ ก็มีความเป็นไปได้สูงว่าจะบอกให้ลองใช้ OpenD
- จะไม่เข้าร่วมประชุม DLF เว้นแต่จะยอมรับการเปลี่ยนแปลง governance เป็นเงื่อนไขล่วงหน้า
- แม้ได้รับคำเชิญเข้าร่วมไลฟ์สตรีม DConf Online ก็จะปฏิเสธ
- ไลบรารี D จะรักษา คำมั่นเรื่องความเข้ากันได้ ระหว่างเวอร์ชันภายในกับอัปเดตคอมไพเลอร์ภายนอก เฉพาะเป้าหมายที่มีสัญญาสนับสนุนแบบชำระเงินเท่านั้น
- สำหรับผู้ใช้อื่น ความเข้ากันได้กับ upstream D จะถูกยกเลิกทันที
- โค้ดถูกจัดให้ตามสภาพ โดยไม่มีการรับประกันใด ๆ ทั้งโดยชัดแจ้งหรือโดยนัย
- หากเข้าร่วมฟอร์ก OpenD การสนับสนุนไลบรารีดังกล่าวจะดำเนินต่อไป
- แอปพลิเคชัน D ก็เช่นเดียวกับไลบรารี คือไม่มีคำมั่นเรื่องความเข้ากันได้กับ upstream D และเนื่องจากเดิมออกแบบมาเพื่อใช้เอง การรับประกันความเข้ากันได้จึงหลวมกว่า
จุดยืนที่เหลืออยู่
- ระบุว่าใช้เวลาจำนวนมากกับ D ตลอด 16 ปีที่ผ่านมา และอาชีพการเขียนโปรแกรมส่วนใหญ่เกิดขึ้นได้เพราะ D และ Digital Mars C++ ก่อนหน้านั้น
- Walter Bright และเพื่อนร่วมงานมีอิทธิพลอย่างมากต่อชีวิต และประเมินว่า Walter เป็นผู้มีส่วนร่วมที่ยอดเยี่ยมในโปรเจกต์ภาษาโปรแกรม
- แต่ถึงอย่างนั้น ตอนนี้ก็จะออกจาก D ของ Walter Bright และเลือกเส้นทางแยกต่างหากชื่อ OpenD
- OpenD ยังมีงานให้ทำอีกมากเพื่อให้สำเร็จ และมีโอกาสล้มเหลวสูงมาก แต่ตอนนี้มองว่าความรับผิดชอบต่อความล้มเหลวอยู่ที่ฝ่าย OpenD เองเท่านั้น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
อย่างน้อย Walter และอาจรวมถึง ผู้นำของ D คนอื่น ๆ ก็ใช้งานอยู่ที่นี่ จึงมีโอกาสสูงที่จะได้เห็นความคิดเห็นเหล่านี้
อยากให้ระลึกไว้ว่า พวกเขาก็เป็นมนุษย์เหมือนกัน รัก D จริง ๆ และจากประสบการณ์ของผม พวกเขาเป็นคนดีโดยพื้นฐานที่พยายามทำให้ดีที่สุด
ไม่รู้ว่าทำไมตอนนี้ถึงคิดว่าจะต่างออกไป และรู้สึกเหมือนเป็นการซ้ำรอย Tango ภาค 2
ต่างกันแค่ว่าตอนนี้เรือออกไปนานแล้ว
ถ้าโปรเจกต์อาจไปได้ดีกว่าภายใต้ผู้นำแบบอื่น ก็ควรพิจารณาความเป็นไปได้นั้น
โดยส่วนตัวผมอยากให้ D กลับมามีชีวิตชีวาอีกครั้งจริง ๆ และจนถึงตอนนี้ก็ยังเป็นภาษาที่ผมชอบที่สุด
ไม่ได้จะโจมตี Walter หรือใครทั้งนั้น พวกเขาเป็นแค่คนที่พยายามรักษาสิ่งที่ตนรักไว้
น่าเสียดาย แต่เรื่องแบบนี้คงต้องเกิดขึ้นในที่สุด เพราะมีการพูดถึง การฟอร์ก D กันมากเกินไปมาหลายปีแล้ว
ตอนที่หนังสือของ Andrei Alexandrescu ออกมาในปี 2010 แทบทุกอย่างที่ดีใน D ก็เข้าไปอยู่ใน C#, Java, C++ แล้ว
การนำไปใช้อาจไม่เรียบร้อยเท่า D แต่ถ้าสามารถใช้ได้ในรูปแบบใดรูปแบบหนึ่งภายในระบบนิเวศของเครื่องมือและไลบรารีที่ดีกว่า ความต่างนั้นก็ไม่ได้สำคัญมากนัก
เสียเวลาไปมากเกินกับการไล่ตามฟีเจอร์ทองคำที่จะดึงดูดผู้คนเข้ามา และก็ยังทำให้ฟีเจอร์เหล่านั้นเสถียรไม่ได้
ทุกวันนี้ Andrei ก็ดูเหมือนจะยุ่งกับ C++ และ CUDA มากกว่า D
ตลอด 10 ปีที่ผ่านมา ยังมีการฟื้นตัวของภาษาโปรแกรมที่คอมไพล์เป็นเนทีฟเข้ามาซ้ำเติม ทำให้การแข่งขันหนักขึ้นอีก
นั่นจึงยิ่งน่าเสียดาย เพราะในชุมชนเองมีคนยอดเยี่ยมจำนวนมากที่คุยด้วยแล้วดี
ผมใช้ Python ทุกวัน และมีหลายอย่างใน D ที่คิดถึง
ยังไม่ต้องพูดถึงเรื่องประสิทธิภาพด้วยซ้ำ
ในฐานะคนนอกที่เคยดู D อยู่ ผมเห็นเรื่องคล้าย ๆ กัน
ตอนที่ Rust ยังใหม่ ๆ แนวคิดเรื่อง lifetime ถูกเสนอในชุมชน D แต่ Walter มองว่าไม่จำเป็น
ไม่กี่ปีต่อมา Walter นำข้อเสนอ lifetime ของตัวเองที่ต่างจาก Rust พอสมควรมาเสนอ ดังนั้นจึงผ่านการตรวจสอบมาน้อยกว่าข้อเสนอเดิมของชุมชน
ตอนนี้ผมหมดความสนใจใน D ไปแล้ว จึงไม่รู้ว่าฟีเจอร์ lifetime ใหม่นั้นสุกงอมแค่ไหน แต่ถ้ามันมีประโยชน์เท่า Rust ผมคงแปลกใจ
ไม่ว่าฟีเจอร์ใดก็มีจุดแลกเปลี่ยน เช่น การโต้ตอบกับฟีเจอร์ภาษาอื่น ภาระทางความคิด ความเร็วคอมไพล์ที่ลดลง ความซับซ้อนของการออกแบบไลบรารีมาตรฐาน และการทำให้ความเข้ากันได้ย้อนหลังพัง
ผมคิดว่าไม่สมเหตุสมผลที่จะคาดหวังการยกเครื่องขนานใหญ่เพื่อรองรับฟีเจอร์หนึ่งที่ชอบจากภาษาอื่น
กลุ่มวิจัยของผมย้ายจาก 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 มุ่งเน้นไปที่ garbage collector อย่างเต็มตัว ผมยังสับสนว่ามันจะเล็งตลาดเฉพาะกลุ่มไหน
ก่อนหน้านี้ก็ไม่ได้มีช่องว่างเฉพาะที่ชัดเจนอยู่แล้ว โดยพื้นฐานแล้วมันคือ “C++ ที่ดีกว่า 10%” และเพราะไม่มีฟีเจอร์เด็ดที่แตกต่างชัดเจน จึงขายยาก
คนส่วนใหญ่น่าจะยังอยู่กับ C++ เพราะการซัพพอร์ตเดิม โค้ดเบส และฐานอุตสาหกรรม หรือใช้ Rust สำหรับโปรเจกต์ใหม่ หรือถ้าต้องการความเรียบง่ายก็อาจใช้ Zig
โดยเฉพาะหลัง C++20 ก็เหมือนว่ามี “C++ ที่ดีกว่า 10%” อยู่แล้ว
อีกอย่าง ผมก็ไม่แน่ใจว่าการมุ่งไปที่ garbage collector จะช่วยได้มากแค่ไหน
แบบนั้นก็จะต้องแข่งกับ C# และ Java ซึ่งทั้งสองเป็นภาษาที่ถูกตั้งใจให้เป็นผู้สืบทอด C++ ที่มี garbage collection ปลอดภัย และกระชับมาตั้งแต่แรก และตอนนี้ก็ยังมองไม่ค่อยออกว่าจะไปแข่งกับสองภาษานี้ได้อย่างไร
โดยเฉพาะ C# นอกจากจะมีฟีเจอร์ระดับต่ำ/unsafe ที่ค่อนข้างดี เช่น raw pointer, การควบคุม reference type/value type, การควบคุม memory layout แล้ว ยังมี type system และ reflection ที่ใช้ได้สำหรับภาษาเก่าแก่ที่เน้น OOP เป็นหลัก และยังรับฟีเจอร์สาย ML เข้ามาเรื่อย ๆ
พูดตรง ๆ วิสัยทัศน์ของ D ทำให้ผมสับสนมาตลอด
ผมเคยอ่านเอกสารของฟีเจอร์ภาษาเฉพาะอย่าง BetterC, safe mode, lifetime แต่ในเชิงไวยากรณ์อ่านยาก และถึงจะมีรายละเอียดเยอะ โดยรวมก็อธิบายได้ไม่ดีนัก
ผมไม่ค่อยรู้สึกถึงวิสัยทัศน์หรือเป้าหมายการออกแบบภาษาที่สอดคล้องกัน
ผู้เขียนพูดถึงปัญหานี้ก็จริง แต่ดูเหมือนวิสัยทัศน์ของพวกเขาก็ไม่ได้ชัดเจนขึ้นเท่าไร
การมีเป้าหมายทางเทคนิคระยะกลางที่เป็นรูปธรรมอยู่บ้างเป็นเรื่องดี แต่ไม่ชัดเจนว่าเป้าหมายเหล่านั้นมีไว้เพื่ออะไร
ผมเป็นโปรแกรมเมอร์ Rust จึงเดาได้อยู่แล้วว่าจะใช้อะไรกับโปรเจกต์ส่วนตัวใหม่ ๆ แต่ถ้าต้องเลือกอย่างอื่น ผมคงใช้ OCaml, C++ หรือแม้แต่ C# มากกว่า
ข้อแรก D เป็นตัวทดแทน C++ แต่ไม่ใช่ C++ และนักพัฒนา C++ จำนวนมากก็หงุดหงิดกับความแตกต่างนั้น
ข้อสอง D ทำได้มากกว่าการเป็นแค่ตัวทดแทน C++ มาก
มันใช้ทำ scripting, เป็นภาษาโปรแกรมมิงทั่วไป และโดยเฉพาะใช้กับ C interoperability อย่าง ImportC และ BetterC ได้
หนึ่งในเป้าหมายของ fork นี้คือการไม่ต้องแก้ตัวเรื่อง garbage collector อีกต่อไป
ใน standard library ก็ยังมี reference counting, unique pointer และอื่น ๆ อยู่
ถ้ามีใครอยาก contribute ฟังก์ชันที่หลีกเลี่ยง garbage collector ผมคิดว่าน่าจะถูกรับ
เพียงแต่ใน fork นี้ คงมีโอกาสน้อยที่จะเห็น Adam พยายามมากเกินไปเพื่อเลี่ยง garbage collector ตอนใส่ฟังก์ชันใหม่เข้า standard library
เขาเชื่อว่าความกลัวต่อ garbage collector นั้นถูกพูดเกินจริง
ตลอด 10 ปีที่ผ่านมา มีเรื่องให้เรียนรู้มากมายเกี่ยวกับ governance ของภาษาโปรแกรมมิง
เมื่อดูภาษาที่กำลังเติบโตและเปลี่ยนแปลง พวกมันเองก็เคยเจอความขัดแย้งหรือความผิดพลาดใหญ่ ๆ ด้าน governance เช่นกัน
ตอนนี้ผมคิดว่าสิ่งสำคัญที่ต้องดูเมื่อมองภาษาโปรแกรมมิงคือ governance
ต้องดูว่าพวกเขาพูดถึงวิธีดำเนินงานอย่างไร ในความเป็นจริงทำอย่างไร ผลลัพธ์จนถึงตอนนี้เป็นอย่างไร และต่อไปน่าจะเป็นอย่างไร
วิวัฒนาการของภาษาโปรแกรมมิงแทบจะเป็นเรื่องของ การจัดการความซับซ้อน และขณะเดียวกันก็ต้องถ่วงดุลความต้องการของผู้มีส่วนได้ส่วนเสียหลายฝ่าย
ความขัดแย้งด้าน governance แทบทั้งหมดเกิดขึ้นเมื่อกลุ่มผู้มีส่วนได้ส่วนเสียกลุ่มหนึ่งไม่พอใจกับข้อกำหนดที่จำเป็นต่ออีกกลุ่มหนึ่ง และไม่สามารถทำให้ทั้งสองฝ่ายพอใจได้เสมอไป
asyncของ Rust เป็นกรณีที่เป็นที่รู้จัก ซึ่งอธิบายการออกแบบที่ใช้งานได้ แต่โดยรวมไม่น่าพอใจGo เป็นข้อยกเว้นที่หาได้ยาก เพราะ core team ไม่มีเหตุผลที่จะต้องเคารพผู้มีส่วนได้ส่วนเสียทุกฝ่าย และมีทั้งทรัพยากรกับเจตจำนงเพียงพอจะทำเช่นนั้น แต่ก็ยังมีความขัดแย้งบางส่วนเกิดขึ้นอยู่ดี
โมเดลการเขียนมาตรฐาน ในช่วงทศวรรษ 1960–1980 ดีกว่ามาก และยังจำกัดการต่อสู้ทางการเมืองให้อยู่ในช่วงเวลาสั้น ๆ ด้วย
ผมไม่ค่อยเข้าใจว่าการมี compiler implementation หลายตัวมีข้อเสียอะไร
โดยส่วนตัวคิดว่านั่นเป็นเหตุผลหลักที่ทำให้ C แพร่หลายขนาดนั้น
compiler แต่ละตัวสามารถสำรวจทิศทางที่ต่างกันได้ และ language extension ที่พิสูจน์คุณค่าแล้ว สุดท้ายก็มักถูก implementation อื่นนำไปใช้ด้วย และบางครั้งก็เข้าไปอยู่ในมาตรฐานโดยไม่ถูกทำให้เสียรูปมากเกินไปในกระบวนการหาฉันทามติของคณะกรรมการ
อย่างน้อยผมคิดว่ามี 2 ตัว คือ implementation ฝั่ง gcc กับ dlang