ความเข้ากันได้ย้อนหลัง, Go 1.21 และ Go 2

 (go.dev)
2 คะแนน โดย GN⁺ 2023-08-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความว่าด้วยความสำคัญของความเข้ากันได้ย้อนหลังในภาษาโปรแกรม Go โดยเน้นฟีเจอร์ใหม่ของ Go 1.21 และอนาคตของ Go 2
  • Go 1.21 มีฟีเจอร์ใหม่ที่ช่วยปรับปรุงความเข้ากันได้ โดยมีเป้าหมายเพื่อให้ Go คงความเสถียรและคาดการณ์ได้ เพื่อให้นักพัฒนาสามารถโฟกัสกับงานได้มากกว่าการเปลี่ยนแปลงของภาษา
  • ทีม Go ให้ความสำคัญกับความเข้ากันได้มาเป็นเวลากว่า 10 ปี โดยมีเจตนาที่ชัดเจนว่าโปรแกรมที่เขียนตามสเปก Go 1 จะต้องคอมไพล์และทำงานได้อย่างถูกต้องโดยไม่ต้องแก้ไขตลอดอายุของสเปกนั้น
  • อธิบายแนวทางหลักสองประการในการรักษาความเข้ากันได้: การตรวจสอบ API และการทดสอบ การตรวจสอบ API ช่วยรับประกันว่า API เดิมจะไม่ถูกลบหรือเปลี่ยนแปลงในลักษณะที่ทำให้โค้ดเดิมเสียหาย ส่วนการทดสอบคือการรันชุดทดสอบเดิมกับเวอร์ชันพัฒนาของ Go รุ่นถัดไป
  • ยกตัวอย่างปัญหาความเข้ากันได้แบบละเอียดอ่อนที่ค้นพบจากการทดสอบ Go ภายใน Google เช่น struct literal กับฟิลด์ใหม่ และความละเอียดของเวลา
  • จัดหมวดหมู่ปัญหาความเข้ากันได้ออกเป็น 3 ประเภท: การเปลี่ยนแปลงเอาต์พุต การเปลี่ยนแปลงอินพุต และการเปลี่ยนแปลงโปรโตคอล
  • Go 1.21 ปรับปรุงความเข้ากันได้ย้อนหลังด้วยการขยายและทำให้การใช้ GODEBUG เป็นทางการ โดยการตั้งค่า GODEBUG จะคงไว้เป็นเวลาอย่างน้อย 2 ปี และจะถูกตั้งให้สอดคล้องกับเวอร์ชัน Go ที่ระบุในไฟล์ go.mod ของแพ็กเกจหลัก
  • บทความปิดท้ายด้วยอัปเดตเกี่ยวกับ Go 2 โดยประกาศว่าจะไม่มี Go 2 ที่ทำให้โปรแกรม Go 1 ใช้งานไม่ได้ แต่ทีม Go จะให้ความสำคัญกับความเข้ากันได้เป็นอันดับแรก และเชื่อว่านี่คือการตัดสินใจด้านการออกแบบที่สำคัญที่สุดสำหรับ Go 1

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-15
ความคิดเห็นบน Hacker News
  • บทความนี้พูดถึงความสำคัญของความเข้ากันได้ย้อนหลังใน Go 1.21 และ Go 2 ที่อาจเกิดขึ้นในอนาคต
  • Go 1.21 มีความสามารถเฉพาะตัวสองอย่าง: การตั้งค่า GODEBUG สำหรับการเปลี่ยนแปลงแต่ละรายการพร้อมเมตริกเพื่อตรวจจับการใช้งาน implementation เดิม และเวอร์ชัน toolchain รายโมดูลที่ดึงทั้ง go toolchain เก่าและใหม่มาโดยอัตโนมัติ
  • เมื่อระบุ Go เวอร์ชันที่เฉพาะเจาะจงแล้ว Go เวอร์ชันใหม่จะใช้การตั้งค่าที่เกี่ยวข้องแบบ opt-out โดยอัตโนมัติ เพื่อไม่ให้นำพฤติกรรมใหม่มาใช้จนกว่าจะมีการร้องขอ
  • ทีมภาษา Go มุ่งมั่นที่จะรักษาความเข้ากันได้ย้อนหลัง และสิ่งนี้ได้รับการยอมรับจากนักพัฒนาที่ดูแลระบบ Go ขนาดใหญ่
  • ผู้ใช้บางรายแสดงความกังวลว่าการปรับปรุงสำคัญต่อระบบชนิดข้อมูลอาจต้องอาศัยการเปลี่ยนแปลงที่ไม่เข้ากันแบบเดิม
  • มีข้อเสนอว่า Go ไม่ควรมี Go 2 จริง ๆ เพราะการเปลี่ยนแปลงสำคัญอาจทำให้ต้องแยกภาษาและเปลี่ยนชื่อ
  • ความเสถียรและความคาดเดาได้ของ Go ที่ถูกอธิบายว่า "น่าเบื่อ" นั้นตัดกับ ecosystem ของ JavaScript ที่แตกกระจายและเปลี่ยนแปลงอยู่ตลอดเวลา
  • บทความนี้ยังกล่าวถึงโพสต์ที่เกี่ยวข้องเรื่อง "Forward Compatibility and Toolchain Management in Go 1.21"
  • ความมุ่งมั่นต่อความเข้ากันได้ย้อนหลังใน Go ได้รับคำชื่นชม โดยมีผู้ใช้คนหนึ่งแชร์ว่าการย้ายโค้ดจาก Python ไป Go ช่วยให้พวกเขาขยายระบบได้อย่างไร
  • เทคนิคที่ Go ใช้เพื่อรับประกันความเข้ากันได้ได้รับความชื่นชม และมีการพิจารณานำไปใช้ในการออกแบบภาษาอื่นด้วย