ข้อเสนอให้เพิ่มแพ็กเกจ UUID ในไลบรารีมาตรฐานของ Go

 (github.com/golang)
1 คะแนน โดย GN⁺ 2026-03-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการถกเถียงกันบน GitHub เกี่ยวกับข้อเสนอให้ รวมความสามารถในการสร้างและพาร์ส UUID ไว้ในไลบรารีมาตรฐาน ของภาษา Go
  • ผู้เสนอให้เหตุผลว่าในปัจจุบันโปรเจ็กต์เซิร์ฟเวอร์และฐานข้อมูลของ Go ส่วนใหญ่ พึ่งพาแพ็กเกจนอก อย่าง github.com/google/uuid
  • ภาษาหลักอย่าง C#, Java, Python เป็นต้น ต่างก็มี การรองรับ UUID ในระดับไลบรารีมาตรฐาน อยู่แล้ว
  • ระหว่างการอภิปราย ประเด็นสำคัญได้แก่สเปกล่าสุดอย่าง UUIDv7, การปฏิบัติตาม RFC 9562, ขอบเขตของความสามารถในการพาร์ส และความสม่ำเสมอของ API
  • ต่อมาข้อเสนอนี้ถูกรวมเข้าไปอยู่ใน ข้อเสนอรองรับ UUIDv4·UUIDv7 ของแพ็กเกจ crypto/rand (#76319) และกำลังดำเนินต่อในเส้นทางนั้น

ภาพรวมของข้อเสนอ

  • มีการเสนอแนวทางเพิ่ม API สำหรับสร้างและพาร์ส UUID ลงในไลบรารีมาตรฐานของ Go
    • เวอร์ชันเป้าหมายคือ UUID v3, v4, v5
    • เหตุผลหลักคือการพึ่งพาแพ็กเกจนอกและกรณีตัวอย่างของการรองรับเป็นมาตรฐานในภาษาอื่น
  • UUID เป็นมาตรฐานสากลที่กำหนดไว้ใน RFC 4122 (ภายหลังคือ RFC 9562)
  • ผู้เสนอชี้ว่า Go เป็นกรณีที่ค่อนข้างผิดปกติในบรรดาภาษาหลัก เพราะ ยังไม่มีการรองรับ UUID แบบมาตรฐาน

ปฏิกิริยาแรกเริ่มและการอภิปราย

  • ผู้เข้าร่วมบางส่วนกล่าวถึงว่าในอดีตก็เคยมีข้อเสนอคล้ายกันแต่ ถูกปฏิเสธมาแล้ว (#23789, #28324)
    • เหตุผลคือการใช้แพ็กเกจนอกนั้นสะดวกเพียงพออยู่แล้ว และมี รอบการออกรุ่นที่ยืดหยุ่นกว่า ไลบรารีมาตรฐาน
  • ผู้เสนอแย้งว่า “ถ้าโปรเจ็กต์ส่วนใหญ่ต้อง import แพ็กเกจนอกทุกครั้งอยู่แล้ว ก็รวมไว้ในมาตรฐานไปเลยน่าจะดีกว่า”
  • อีกเหตุผลที่ใช้สนับสนุนคือหลายภาษามักรวม UUID ไว้ใน ไลบรารีมาตรฐานฝั่งที่เกี่ยวข้องกับ crypto

UUID เวอร์ชันใหม่และการสะท้อนตาม RFC

  • ความเห็นบางส่วนชี้ว่า UUID v1~v5 ล้าสมัยแล้ว และ v7 คือเวอร์ชันใหม่ที่น่าสนใจที่สุด
    • v7 มีตัวเลือกในการติดตั้งใช้งานหลายแบบ จึงควรรอดูผลจากการใช้งานจริงเพิ่มเติม
  • ในร่าง RFC มีคำแนะนำว่า ไม่ควรพาร์ส UUID โดยไม่จำเป็น และควรปฏิบัติกับมันในฐานะตัวระบุแบบทึบแสง
  • หลังจาก RFC 9562 ถูกประกาศใช้อย่างเป็นทางการ การอภิปรายที่เกี่ยวข้องก็ ย้ายมาโฟกัสที่การรองรับ UUIDv7

การแก้ไขและการรวมข้อเสนอ

  • ในปี 2025 เมื่อ RFC 9562 มีผลอย่างเป็นทางการ ก็มีการกล่าวถึงว่า PostgreSQL 18 รองรับ UUIDv7 แล้ว
  • หลังจากนั้นฝั่ง Go ก็เริ่มข้อเสนอแยกต่างหากคือ เพิ่มเฉพาะความสามารถสร้าง UUIDv4·UUIDv7 ในแพ็กเกจ crypto/rand (#76319)
    • ความสามารถในการพาร์สถูกตัดออกตามคำแนะนำของ RFC
  • ข้อเสนอเดิม (#62026) จึงถูกปิดโดยระบุว่าเป็น รายการซ้ำซ้อน (duplicate)

การอภิปรายด้านการออกแบบ API

  • มีการถกเถียงกันว่าพฤติกรรมเริ่มต้นของ uuid.New() ควรเป็น v4 หรือควรเปิดทางให้เปลี่ยนในอนาคต
    • บางส่วนเสนอว่า “ถ้าเปลี่ยนเวอร์ชันทีหลังอาจเกิดปัญหาความเข้ากันได้” จึงควร ตรึงไว้ที่ v4 เสมอ
  • มีการหารือว่าจะควรมีเมธอดอย่าง Compare, MustParse, Parse หรือไม่
    • มีความเห็นว่า Compare จำเป็นสำหรับการรองรับ UUID ที่สามารถจัดเรียงได้ ตามนิยามของ RFC
    • ส่วน MustParse ควรรวมไว้เพื่อให้สอดคล้องกับฟังก์ชันตระกูล Must* อื่น ๆ ในไลบรารีมาตรฐาน
  • สรุปว่าเมธอด IsZero() นั้นไม่จำเป็นสำหรับชนิด UUID
  • มีการเสนอแนวคิดด้านการออกแบบหลายแบบ เช่น การเพิ่มโครงสร้าง Generator, การแยกชนิดตามเวอร์ชัน (UUIDv4, UUIDv7 เป็นต้น)
  • บางส่วนชี้ว่าฟังก์ชัน New() มีความกำกวม และเสนอให้มีเฉพาะ ฟังก์ชันที่ระบุเวอร์ชันชัดเจน (NewV4, NewV7)

ประเด็นทางเทคนิคสำคัญ

  • มีการถกเถียงว่าคำนิยามของ การจัดเรียง UUID (sorting) นั้นชัดเจนเฉพาะใน v6·v7 หรือไม่
  • มีการพิจารณาวิธีทำให้ การสร้าง UUIDv7 รองรับการเรียงตามเวลา และ ป้องกันการชนกันในการทำงานพร้อมกัน (แนวทางแบบ counter)
  • มีการชี้ว่าความหมายของแต่ละเวอร์ชัน แตกต่างกันโดยเนื้อแท้ (เช่น v1 มี MAC address, v7 อิงเวลา) ทำให้การออกแบบเป็นชนิดเดียวมีข้อจำกัด
  • บางส่วนเสนอให้ แยกชนิดตามเวอร์ชันและมีเมธอดแปลงแบบชัดเจน เช่น AsV4(), AsV7()

บทสรุปและสถานะปัจจุบัน

  • โดยรวมแล้วชุมชน Go เห็นพ้องค่อนข้างมากว่าจำเป็นต้องมีการรองรับ UUID แบบมาตรฐาน
  • อย่างไรก็ตาม เพื่อรักษา ความเรียบง่ายของไลบรารีมาตรฐาน และ ปฏิบัติตามคำแนะนำของ RFC จึงสรุปแนวทางว่า
    • ตัดความสามารถในการพาร์สออก
    • เพิ่มเฉพาะความสามารถสร้าง UUIDv4·UUIDv7 ลงใน crypto/rand
  • ข้อเสนอเดิม (#62026) ถูก รวมเข้าเป็นส่วนหนึ่งของข้อเสนอ #76319 และกำลังดำเนินอยู่
    สถานะตอนนี้คือการ รองรับ UUID แบบมาตรฐานในภาษา Go กำลังเข้าใกล้ขั้นตอนการรับรองอย่างเป็นทางการ

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

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

 
GN⁺ 2026-03-08
ความเห็นจาก Hacker News

  • น่าสนใจที่มีคนบอกว่า UUID เวอร์ชัน 1~5 ล้าสมัยไปแล้ว
    แต่ v4 ก็ยังคงมีความสุ่มสูงที่สุด และยังแนะนำให้ใช้เป็นคีย์หลักเพื่อหลีกเลี่ยงทั้ง ปัญหา hotspot และประเด็นด้านความเป็นส่วนตัว ใน distributed DB
    ลิงก์อ้างอิง: เอกสาร UUID ของ CockroachDB, คู่มือ UUID ของ Google Cloud Spanner

    • ฉันก็คิดว่าคำพูดนั้นแปลกเหมือนกัน v7 ดีเมื่อจำเป็นต้องมีความเป็นลำดับเดียวกัน แต่ timestamp อาจเผยข้อมูลของระบบได้ ดังนั้น v4 ก็ยังใช้ได้อยู่
    • ฉันคิดว่าคำว่า “outdated” ไม่เหมาะสม ประเด็นจริงคือ ความต้องการไม่ตรงกัน ไม่ใช่เรื่องอายุ
      UUID แต่ละเวอร์ชัน (รวมถึง v4) ต่างก็มีข้อบกพร่องในบางสถานการณ์ และในความเป็นจริงหลายองค์กรก็ใช้ ค่า 128 บิตล้วน ๆ ที่นิยามเองแทน UUID มาตรฐาน
      ท้ายที่สุดแล้ว ความต้องการที่ซับซ้อนจำนวนมากก็เกินข้อจำกัดด้านการออกแบบของ UUID ไปแล้ว
    • v4 คือทางเลือกเริ่มต้น และจะใช้เวอร์ชันอื่นก็ต่อเมื่อต้องการ การคงลำดับ เป็นพิเศษเท่านั้น
    • ถ้าต้องการความสุ่ม 128 บิตจริง ๆ ก็ใช้เลขสุ่ม 128 บิตไปเลย ไม่จำเป็นต้องยัดให้เข้ากับฟอร์แมต UUID
    • แต่ v4 อาจทำให้ การแทรกใน B-Tree ยุ่งเหยิงได้ ฉันเคยเรียนมาว่า v7 เร็วกว่ามากเพราะประสิทธิภาพของ page caching ในเคอร์เนล

  • รู้สึกดีที่วันนี้บน HN มี ข่าว Go เล็ก ๆ น้อย ๆ แบบนี้ขึ้นมา
    ช่วงนี้มีแต่เรื่องอนาคตของการเขียนโปรแกรมหรือเรื่อง AI กันหมด หัวข้อเทคนิคแบบนี้เลยสดใหม่ดี

    • ดีใจที่ได้เห็น การถกเถียงเชิงเทคนิคแบบลงลึก อีกครั้งหลังจากไม่ได้เห็นมานาน
    • ได้พักจากความหวาดกลัว (FUD) เรื่อง AI ชั่วคราวแล้วรู้สึกสบายใจ แต่ก่อนเปิด HN แล้วไม่ได้รู้สึกกังวลแบบนี้ เดี๋ยวนี้มีแต่คนพูดว่า “ทุกอย่างกำลังจะพัง”
    • ดูเผิน ๆ เหมือนเป็นประเด็นเทคนิคเล็ก ๆ แต่จริง ๆ แล้วมันคือการตัดสินใจใหญ่ที่กำหนด สถาปัตยกรรมของภาษา Go และทิศทางของผู้นำโครงการ
      ทั้งกลุ่มสายสมบูรณ์แบบ นักพัฒนาสายปฏิบัติจริง และ ชุมชน crypto ต่างก็มีจุดยืนของตัวเอง
      เอกสารที่เกี่ยวข้อง: RFC 9562
      ฉันหวังว่า Go จะตัดสินใจได้ถูกต้อง โดยเฉพาะ TinyGo ที่เจ๋งมากสำหรับไมโครคอนโทรลเลอร์
    • ภาพรวมของคนที่ไม่ชอบ Go ก็น่าสนใจดี ตอนนี้เป็นยุคที่ AI อ่านโค้ด แล้ว ดูเหมือนความสนุกในการวิจารณ์ภาษาก็หายไปด้วย

  • ฉันไม่ได้สนใจมากนักว่า Go จะรองรับการสร้าง UUID หรือไม่ แต่การมี ชนิดข้อมูล UUID มาตรฐาน นั้นสำคัญมาก
    มันจะทำให้การ marshal แบบสอดคล้องกันใน JSON, Text, database/sql และอื่น ๆ เป็นไปได้
    ในการวิเคราะห์ dependency ของ Go เมื่อไม่นานมานี้ google/uuid เป็นแพ็กเกจที่ถูกใช้มากเป็นอันดับสอง
    บทวิเคราะห์ที่เกี่ยวข้อง: The most popular Go dependency

    • ฉันเองก็อยากให้มีชนิด dec128 เข้ามาเป็นมาตรฐานเหมือนกัน ถ้าให้มาในรูปแบบ struct ที่แปลงเป็น uint128 ได้ง่ายก็น่าจะดีมาก

  • เสน่ห์ของ Go อยู่ที่ ความใช้งานได้จริงมากกว่าฟีเจอร์หวือหวา
    ภาษาไม่ได้ซับซ้อนจนพัง และเพิ่มเฉพาะสิ่งที่จำเป็นเท่านั้น

    • ฉันเองก็เพิ่งอัปเกรดข้ามหลายเวอร์ชันมาไม่นานนี้ และไม่มีปัญหาอะไรเลย
      ด้วย การรับประกันความเข้ากันได้ย้อนหลัง จึงใช้งานได้อย่างสบายใจ เป็นภาษาที่เปลี่ยนแปลงช้าแต่ดีขึ้นอย่างต่อเนื่อง

  • สำหรับฉัน สิ่งที่สำคัญกว่าการที่แพ็กเกจ uuid ของ Google ไม่ค่อยเคลื่อนไหวแล้ว คือการที่ gofrs/uuid ปฏิบัติตามมาตรฐานใหม่และยังได้รับการดูแลอย่างต่อเนื่อง
    คลังเก็บ gofrs/uuid

    • การสร้างไลบรารีที่ไม่มี external dependency เป็นเรื่องสนุก และการเปลี่ยนแปลงครั้งนี้จะทำให้ทำแบบนั้นได้ง่ายขึ้น
    • แต่ google/uuid ไม่มีรีลีสหลังปี 2024 และแม้แต่ในเดือนมิถุนายน 2025 ก็ยังมีการเปิด issue ที่เกี่ยวข้องอยู่
      issue #194
    • ข้อเสนอนี้ถูกพูดคุยมาตั้งแต่ 3 ปีก่อนแล้ว

  • ฉันเกลียด UUID มาก มันเป็น ตัวระบุที่ไม่เป็นมิตรกับมนุษย์
    เวลา debug หรือดูผลลัพธ์ query มันยาวเกินไปและใช้งานลำบาก
    แน่นอนว่ามันมีประโยชน์เมื่อจำเป็นต้องมี ID ที่ไม่ซ้ำกันระหว่างระบบที่แยกขาดจากกันโดยสิ้นเชิง แต่ส่วนใหญ่แล้วมันถูกใช้เกินความจำเป็น
    ในกรณีทั่วไป ตัวออกเลขแบบรวมศูนย์ ดีกว่ามาก
    เช่นขั้นตอนอย่าง GetNextId ใน DB ที่ทั้งเป็นมิตรกับคนและมีประสิทธิภาพกว่า

    • เมื่อก่อนที่บริษัท ฉันเคยใช้โค้ด 6 หลักสำหรับจัดการโปรเจกต์ แต่มีคนเปลี่ยนมันเป็น UUID
      ผลคือมันกลายเป็น โค้ดที่มนุษย์อ่านไม่ออก และแย่กว่านั้นคือเป็น implementation ทำเองที่มีลักษณะเรียงลำดับแบบประหลาด เป็นการตัดสินใจที่พังมาก
    • จริง ๆ แล้วในกรณีส่วนใหญ่ ตัวนับแบบจำนวนเต็ม ก็เพียงพอ
      ถ้าใช้ตาราง counter ใน Postgres ก็สามารถสร้าง ID ได้หลายหมื่นรายการต่อวินาที
      วิธีนี้ยังช่วยให้ ประหยัดหน่วยความจำ บีบอัดได้ดีขึ้น และเพิ่มประสิทธิภาพของแฮชแมป อีกด้วย
      UUID นั้นสะดวก แต่ทำลายประสิทธิภาพ
    • อยากให้มันมีองค์ประกอบที่อ่านง่ายสำหรับมนุษย์อยู่บ้าง
      เช่นรูปแบบ BASKETBALL-...-FISH ที่ใส่ checksum แบบใช้คำ เพื่อให้จำง่ายขึ้น
    • มีการพูดถึง “deterministic randomization” และฉันก็คิดว่าวิธีอย่าง LFSR (linear feedback shift register) ก็น่าสนใจเหมือนกัน

  • ฉันสงสัยว่า Go จะเพิ่ม UUID จริงหรือเปล่า

    • ตอนนี้อยู่ในสถานะ ‘Likely accept’ สามารถดูได้จาก บอร์ดโปรเจกต์ Go
      ถ้าไม่มีการคัดค้านเป็นพิเศษ ก็มีโอกาสสูงว่าจะถูกรวมเข้าไป
    • ใช่ มีแผนจะเพิ่มเข้าไป

  • Kotlin เองก็เพิ่งเพิ่ม การรองรับ UUID เวอร์ชันตาม RFC 9562 เข้าไปใน standard library ในเวอร์ชัน 2.3
    รองรับทั้ง JVM, JS, WASM และ Native
    เมื่อ IETF RFC มีความเสถียรแล้ว การที่ Go จะเดินตามก็ถือว่าสมเหตุสมผล

  • ก็น่าเสียดายที่ Go ยัง ขาดการรองรับฟังก์ชันพื้นฐาน แบบนี้

    • ฉันสงสัยว่าภาษาไหนทำเรื่องการทำให้สิ่งเหล่านี้เป็นมาตรฐานได้ดีกว่ากัน Java หรือเปล่า? Python กับ Rust ก็ดูคล้าย ๆ กัน
    • ความหมายของคำว่า “batteries included” เปลี่ยนไปมากในช่วง 20 ปีที่ผ่านมา อาจเป็นฟังก์ชันที่ภายใน Google ไม่เคยจำเป็นต้องใช้ก็ได้
    • UUID ท้ายที่สุดก็เป็นแค่ อาร์เรย์ 16 ไบต์ เท่านั้น การสร้าง v4 ก็ใช้โค้ดไม่กี่บรรทัด จึงไม่ใช่เรื่องใหญ่
    • ฉันสงสัยว่าคุณรู้สึกว่ามันขาดฟังก์ชันอะไร
      สำหรับฉัน ระบบ logging ของ Go เรียบง่ายเกินไปจนต้องทำเอง
      โมดูล slog ทั้งช้าและใช้งานลำบาก ดูเหมือนออกแบบมาโดยมองแต่สภาพแวดล้อมแบบ enterprise
    • ถึงอย่างนั้น คุณภาพของ standard library ของ Go ก็ยังอยู่ในระดับสูงมาก ฉันคิดว่ามันเป็น stdlib ที่ถูกใช้มากที่สุดในงานพัฒนาประจำวัน

  • ฉันเคยคิดว่าจะทำอย่างไรให้ได้ทั้ง ประสิทธิภาพการทำคลัสเตอร์ใน DB ของ v7 และ ความสุ่ม ของ v4 พร้อมกัน
    ถ้าใช้ v7 ภายใน แล้วตอนส่งออกภายนอกค่อย scramble ด้วย XOR หรือ AES ก็น่าจะพอทำได้

    • มีความพยายามแบบนั้นอยู่จริง: โปรเจกต์ uuidv47
    • ถ้าจุดประสงค์คือเรื่องความเป็นส่วนตัว ฉันคิดว่า การเข้ารหัสคีย์แบบจำนวนเต็ม น่าจะดีกว่า
      เช่นถ้าใช้ Feistel encryption ก็สามารถสร้าง public ID ที่ไม่โปร่งใสได้ โดยไม่ต้องเจอปัญหาด้านประสิทธิภาพของ UUID