เปิดตัว Unison 1.0

 (unison-lang.org)
10 คะแนน โดย GN⁺ 2025-11-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Unison คือ ภาษาโปรแกรมเชิงฟังก์ชัน ที่สร้างสถาปัตยกรรมใหม่ทั้งระบบสำหรับการจัดเก็บโค้ด การจัดการเวอร์ชัน และการดีพลอย โดยอิงกับแนวคิดการระบุโค้ดจาก เนื้อหา (Hash) ไม่ใช่ชื่อ
  • โค้ดทั้งหมดไม่ได้ถูกเก็บเป็นไฟล์ข้อความ แต่เก็บอยู่ใน codebase (DB) ทำให้ชื่อเป็นเพียงป้ายกำกับ และช่วยให้ปัญหาอย่าง ชื่อซ้ำ/ไฟล์ชนกัน และความขัดแย้งจากการรีแฟกเตอร์ หายไปในระดับโครงสร้าง
  • ผ่าน UCM (Unison Codebase Manager) ผู้ใช้สามารถ เพิ่ม·ลบ·ย้าย·เปลี่ยนชื่อ·ทดสอบ·รัน definition ได้ และยังมี ระบบนิเวศเครื่องมือสำหรับการทำงานร่วมกัน ที่เชื่อมกับ LSP, UCM Desktop และ Unison Share
  • นอกจากฟีเจอร์ภาษาอย่าง ระบบ effect บนพื้นฐานของ Abilities, delayed computations และ structural pattern matching แล้ว ยังขยายไปสู่โมเดลแบบรวมศูนย์ที่ให้กำหนดทั้ง application logic และการดีพลอยขึ้นคลาวด์ (Cloud/BYOC) ภายในโปรแกรมเดียวกันได้
  • ด้วยโครงสร้างแบบ hash-based ทำให้คุณสมบัติอย่าง การตัดการคอมไพล์ซ้ำ การลดความขัดแย้งของเวอร์ชัน และการค้นหา static reference กลายเป็นคุณสมบัติพื้นฐาน พร้อมมอบ ประสบการณ์การพัฒนาแบบกระจายที่สอดคล้องกัน ผ่านระบบ Share, Cloud, Projects และ Branch

ภาพรวมของภาษา Unison

  • จัดการ definition ด้วยโครงสร้าง content-addressable code ทำให้แม้จะใช้ชื่อเดียวกัน แต่ถ้าเนื้อหาต่างกันก็ถือเป็น definition คนละตัวอย่างสมบูรณ์
    • ไม่ต้องคอมไพล์ใหม่ ลดการชนกันจากการพัฒนา API และคงความเสถียรของการอ้างอิงได้อย่างสมบูรณ์
  • codebase ถูกเก็บเป็น DB บน SQLite โดยโค้ด ชื่อ และเอกสารถูกจัดเก็บเป็นข้อมูลทั้งหมด
    • สำรวจโครงสร้างได้ด้วยคำสั่ง UCM เช่น ls, view
  • ไฟล์ข้อความเป็นเพียงอินเทอร์เฟซสำหรับการแก้ไขเท่านั้น โดย แหล่งข้อมูลจริงหนึ่งเดียวของซอร์สคือ DB
    • แนวคิดอย่างการชนกันของชื่อ การ merge ไฟล์ และการจัดการโครงสร้างรีโพ จึงถูกลดความสำคัญลงจนกลายเป็นเรื่องล้าสมัย

ความสามารถของภาษา

  • Abilities: กลไกควบคุม effect อย่าง IO, Exception ผ่านระบบชนิดข้อมูล
  • Structural pattern matching: แยกโครงสร้างของ type เพื่อสร้าง control flow
  • Delayed computations: แสดงการประเมินผลแบบไม่เคร่งครัดอย่างชัดเจน
  • มี static type ที่แข็งแรง + การอนุมานชนิดข้อมูลที่หลากหลาย + Kind-checking

สภาพแวดล้อมการพัฒนาและ toolchain

  • UCM (Unison Codebase Manager)
    • สร้าง·ลบ·เปลี่ยนชื่อ·ทดสอบ·รัน definition
    • ฝัง version control แบบคล้าย Git เช่น project, branch, clone, merge ไว้ในตัวภาษา
  • UCM Desktop
    • สำรวจโครงสร้าง codebase, ย้ายไปยัง definition แบบคลิกได้, แสดงผลเอกสาร
  • รองรับ LSP
    • ใช้งานฟังก์ชันแบบ IDE ได้กับเอดิเตอร์ยอดนิยมส่วนใหญ่
  • Unison Share
    • ศูนย์กลางโค้ด: โฮสต์โปรเจ็กต์, ค้นหา, รีวิว, ร่วมพัฒนา (=Pull Request), ค้นหาแบบอิง type
    • เพราะทุก definition อิงกับ hash จึง อ้างอิงและกระโดดไปยังปลายทางได้เหมือนไฮเปอร์ลิงก์เสมอ

โมเดลการดีพลอย: Unison Cloud & BYOC

  • ใช้ภาษาเดียวกันเขียนได้ทั้ง application logic + นิยามโครงสร้างพื้นฐาน แล้วดีพลอยได้ทันที
  • สร้างระบบกระจายได้ด้วย “โค้ด” เพียงอย่างเดียว โดยไม่ต้องใช้ YAML, Helm หรือข้อกำหนด RPC ที่ซับซ้อน
  • ด้วย BYOC (Bring Your Own Cloud) จึงสามารถรัน Cloud stack บนโครงสร้างพื้นฐานคอนเทนเนอร์ของตนเองได้
  • มีทั้ง storage ที่ปลอดภัยทางชนิดข้อมูล อย่าง OrderedTable, การรองรับ Daemon และระบบ orchestration อัตโนมัติ

ตัวอย่าง: Guessing Game

  • ตัวอย่าง CLI แบบง่ายที่ใช้ Abilities (IO, Exception)
  • แสดงการผสานกันอย่างเป็นธรรมชาติขององค์ประกอบภาษา เช่น Random, console IO, pattern matching และ delayed computations

ระบบนิเวศและชุมชน

  • รองรับ การร่วมพัฒนา·การรีวิว·บัญชีองค์กร ผ่าน Share
  • ค้นหาทั้ง ecosystem แบบอิง type และมี MCP server สำหรับ AI agent
  • กำลังพัฒนา C FFI อย่างต่อเนื่อง
  • ขยายฟีเจอร์เพิ่มประสิทธิภาพการทำงานร่วมกัน เช่นตัวดู diff สไตล์ Git และคำอธิบายประกอบ branch

ประวัติสำคัญ (สรุป)

  • 2018: ก่อตั้ง Unison Computing
  • 2019: เปิดตัว alpha รุ่นแรก
  • 2021: เปลี่ยน codebase เป็น SQLite (ขนาดเล็กลง 100x)
  • 2021: เปิดตัว Unison Share
  • 2022~2024: LSP, Projects, Kind-checking, Pull Request, Cloud GA
  • 2025: Desktop App, การเพิ่มประสิทธิภาพ runtime ขนาดใหญ่, MCP server, รองรับ BYOC
  • พ.ย. 2025: เปิดตัว Unison 1.0 อย่างเป็นทางการ

FAQ

  • ทำไมต้องเป็นภาษาใหม่?
    • โมเดลโค้ดแบบ hash-based แทบ ไม่สามารถย้ายไปติดตั้งเป็นส่วนเสริมในภาษาที่มีอยู่เดิมได้
    • เพราะแนวทางการเก็บโค้ด การจัดการเวอร์ชัน การดีพลอย และการทำงานร่วมกัน ล้วนต่อยอดมาจากแนวคิดนี้โดยตรง จึงจำเป็นต้อง ออกแบบเป็นภาษาใหม่ตั้งแต่ต้น
  • กรณีใช้งานจริงล่ะ?
    • ระบบ Unison Cloud ทั้งหมด เขียนและใช้งานด้วย Unison เอง
    • มีเวิร์กโฟลว์ระดับเชิงพาณิชย์สำหรับการทำงานร่วมกันในองค์กร/ทีม และการพัฒนาแอปพลิเคชันแบบกระจาย
  • ข้อกังวลเรื่อง vendor lock-in: เป็นภาษาโอเพนซอร์ส ดีพลอยได้อย่างอิสระด้วย Docker เป็นต้น และรองรับ BYOC
  • รูปแบบการทำงานร่วมกัน: รองรับองค์กร, ticket, code review, PR ฯลฯ และจะเกิดความขัดแย้งเฉพาะในระดับ definition เท่านั้น
  • การจัดการเวอร์ชัน: มีระบบ project, branch, push, pull, merge ของตัวเองโดยไม่ต้องใช้ Git
  • ไม่มีข้อจำกัดด้าน IDE: มี LSP server ให้ใช้กับเอดิเตอร์ได้หลากหลาย
  • การเชื่อมต่อกับภาษาอื่น: กำลังพัฒนา C FFI
  • การเข้าถึง codebase ที่ไม่มีไฟล์: สำรวจโครงสร้างได้ผ่านคำสั่ง CLI (UCM) หรือแอป Desktop

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

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

 
GN⁺ 2025-11-27
ความคิดเห็นจาก Hacker News

  • ฉันติดตาม Unison มานานมาก ตั้งแต่สมัยบล็อกส่วนตัวของ Paul ก็เกิน 10 ปีแล้ว การออก 1.0 ครั้งนี้ถือเป็นหมุดหมายใหญ่มาก แต่พูดตรงๆ ก็แอบผิดหวังนิดหน่อย
    ฉันชอบภาษาโปรแกรมมากและเห็นการเติบโตของภาษาอย่าง Rust, Go, Zig มาตลอด แต่รู้สึกว่า Unison ยังขาด แรงขยายของระบบนิเวศ เมื่อเทียบกับระดับความสมบูรณ์ของมัน
    คิดว่าสาเหตุหลักคือโมเดลธุรกิจที่ออกแบบให้ ผูกกับคลาวด์ เป็นส่วนใหญ่ แม้จะมีตัวเลือก BYOC แต่ก็ยังไม่พอ มันให้ความรู้สึกว่าอะไรบางอย่างยังไม่ลงตัว

    • ไม่เห็นด้วยที่จะเอาไปเทียบกับ Zig, Rust, Go เพราะ Unison ใช้ไอเดียที่ “ใหม่และแปลก” อย่าง Abilities หรือ โครงสร้างโค้ดแบบอิงฐานข้อมูล เร็วเกินไป
      โปรเจกต์ Share เป็นโอเพนซอร์ส และ GitHub เองก็มีการพึ่งพาเชิงปฏิบัติเหมือนกันแต่ก็ยังได้รับความนิยมอยู่
      ไม่ได้จะปฏิเสธประเด็นพวกนี้นะ แต่อยากให้คนได้ลองใช้เองและสัมผัสว่าแนวคิดบางอย่างสามารถช่วยงานออกแบบภาษาอื่นๆ ได้
    • ผมคิดว่าปัญหาของ Unison คือ การไม่มี FFI ตรงกันข้าม การโฟกัสกับธุรกิจเป็นกลยุทธ์ที่ดีด้วยซ้ำ ต้องมีรายได้ถึงจะโฟกัสกับฟีเจอร์ที่ผู้ใช้แคร์จริงๆ ได้ และไม่ต้องจมอยู่กับการถกเถียงจุกจิก
    • ฉันก็เห็นด้วย อยากสร้างระบบที่ ทำงานร่วมกันแบบโลคัล ได้แม้ตอนอินเทอร์เน็ตล่ม ซึ่งโครงสร้างฟังก์ชันแบบอิงแฮชเข้ากับสิ่งนั้นมาก
      แต่สื่อการเรียนรู้ส่วนใหญ่ตั้งสมมติฐานว่าต้องใช้โครงสร้างพื้นฐานคลาวด์ ทำให้ทางไปต่อในสภาพแวดล้อมออฟไลน์ตันหมด
      อาจจะมีแนวทางแบบ Unison อยู่ก็ได้ แต่ เลเยอร์การตลาด กำลังบดบังเส้นทางนั้นอยู่
    • กลับรู้สึกดีที่มีทิศทางเชิงพาณิชย์ ถ้าทำดีๆ ก็จะทุ่มเวลาได้มากขึ้นและพัฒนาอย่าง ยั่งยืน ได้
      ถ้ามีผู้ใช้ที่ยอมจ่าย ก็จะมีแรงจูงใจให้เทคโนโลยียังคงอยู่บนฐานที่สมจริงและใช้งานได้จริง
      ถ้าไม่มีองค์ประกอบเชิงพาณิชย์ ก็คงให้ความรู้สึกเหมือนเป็นแค่ esolang อีกตัวหนึ่ง ตอนนี้ฉันตั้งใจจะลองเอาไปใช้ในโปรเจกต์ส่วนตัว
    • ไอเดียแกนหลักเจ๋งมาก แต่ถ้าการแจกจ่ายหรือดึงโค้ดทำได้ผ่าน แพลตฟอร์มคลาวด์ เท่านั้น ก็คงไม่ใช้
      ในเอกสารมีพูดถึง Unison Share ซึ่งก็โฮสต์อยู่บน unison-lang.org เช่นกัน
      แม้จะมีตัวเลือก BYOC แต่ก็ยังต้องมีบัญชี unison.cloud และสมัครสมาชิกอยู่ดี อยากให้เรื่องพวกนี้ระบุให้ชัดในมาร์เก็ตติ้งและเอกสาร

  • สวัสดีครับ ผมเป็นหนึ่งใน ผู้ร่วมสร้าง ภาษา Unison ถ้ามีอะไรสงสัยถามได้ทุกเรื่อง

    • ติดตาม Unison มานาน ขอยินดีกับการปล่อยเวอร์ชัน!
      Unison เป็นหนึ่งในภาษาแรกๆ ที่ชู algebraic effects (Abilities) เป็นฟีเจอร์หลัก
      จำได้ว่าช่วงแรกๆ ยังไม่แน่ใจว่าฟีเจอร์นี้จะได้รับการยอมรับดีแค่ไหน เลยอยากรู้ว่าตอนนี้พอใจไหม
      อยากฟังด้วยว่าระบบเอฟเฟกต์เข้ากับส่วนอื่นของภาษาได้ดีหรือเปล่า ชอบไวยากรณ์ไหม และมีเรื่องน่าสนใจอะไรเกี่ยวกับการทำงานภายในบ้าง
      เอกสารที่เกี่ยวข้อง: Unison Abilities
    • อยากรู้ว่าตอนแคชผลการรันทดสอบ เก็บข้อมูลจริงๆ อะไรไว้บ้าง
      เก็บแค่แฮชของนิพจน์กับค่า “passed” หรือสามารถคำนวณ แฮชของค่าทั้งหมด ได้ด้วย
      ถ้าเป็นอย่างหลัง ก็ดูเหมือนจะต่อยอดแนวคิด การบิลด์ที่ทำซ้ำได้ แบบ Nix หรือ Trustix ได้
      คงเป็นไปได้ว่าตอนนี้การแคชจัดการเฉพาะนิพจน์ที่ bind ไว้ แต่ก็ดูเหมือนอาจทำหน้าที่เป็นสะพานเชื่อมสู่โลกภายนอกตอนรันไทม์ได้ด้วย
    • ยินดีกับการปล่อยเวอร์ชัน! แนวคิดเรื่อง นิยามที่อิงแฮช ของ Unison นั้นล้ำมาก
      แต่ตอนนี้ยังให้ความรู้สึกเหมือนเป็นโซลูชันที่กำลังหาปัญหาอยู่
      อยากรู้ว่าภาษานี้ทำมาเพื่อใคร และนอกจาก Unison Cloud แล้ว มีที่ไหนใช้งานจริงในโปรดักชันบ้างไหม
    • เป็นโปรเจกต์ที่เจ๋งมาก แต่ฉันยังไม่เข้าใจแนวคิด content-addressed language แบบหมดจด
      ตอนแรกนึกว่าเป็นภาษาอยู่บน BEAM แต่จริงๆ รันบน VM ของตัวเอง
      เมื่อเทียบกับภาษาในตระกูล BEAM แล้ว เรื่อง fault tolerance ต่างกันอย่างไร และมีกรณีใช้งานแบบไหนที่ Unison เหมาะกว่าบ้าง
    • อยากรู้ว่า primitive ด้าน persistence อย่าง OrderedTable, Table ถูกทำงานภายในอย่างไร
      มันเรียกฐานข้อมูลภายนอก หรือสร้างขึ้นด้วย Unison เอง
      เมื่อดูร่วมกับ abstraction ของ Database แล้ว เป็นการผสมที่น่าสนใจมาก แต่ทำความเข้าใจแนวคิดทั้งหมดได้ไม่ง่ายเลย

  • ฉันมองว่า Unison เป็นหนึ่งในภาษาที่น่าสนใจที่สุด
    ฉันเชื่อว่า algebraic effects จะเป็นแนวคิดสำคัญของคนรุ่นถัดไป
    นอกจากนี้ Unison ยังมีไอเดียเจ๋งๆ อีกมาก
    ส่วนตัวคิดว่าน่าจะเหมาะกับ การพัฒนาเกมม็อด ด้วย
    เพราะต้องรันโค้ดที่ไม่น่าเชื่อถือได้บนฝั่งไคลเอนต์ และ ระบบ ability ของ Unison น่าจะทำให้สร้างสภาพแวดล้อม sandbox ได้ง่าย
    อีกทั้งยังอาจมีประโยชน์กับการทำ ECS(Entity Component System) ด้วย
    ถ้าสามารถอนุมานความสามารถที่ฟังก์ชันต้องใช้ได้ ก็อาจรับประกันความปลอดภัยในการรันแบบขนานได้โดยอัตโนมัติ

    • ที่จริงแล้ว Unison Cloud ก็ทำ การตรวจสอบ sandbox แบบนี้อยู่
      บน Cloud จะใช้ IO ability โดยตรงไม่ได้ และจะอนุญาตเฉพาะสิ่งอย่าง Http ability ที่ควบคุมอย่างปลอดภัยแทน
      แบบนี้ผู้ใช้ก็จะเข้าถึงระบบไฟล์ไม่ได้
      ผมเองก็กำลังคิดจะใช้ฟีเจอร์นี้กับการพัฒนาเกมเหมือนกัน
      ผู้ใช้อื่นอาจมีส่วนช่วยเกมได้ด้วยการทำ ability เป็น native service
      ลิงก์อ้างอิง: Unison Cloud, โค้ด validateSandboxed, ตัวอย่าง ECS

  • ตอนเห็นโปรเจกต์นี้ครั้งแรก ฉันคิดว่า “อีก 5 ปีข้างหน้าจะเป็นยังไงนะ” แล้วเวลาก็ผ่านไปเท่านั้นจริงๆ
    ดีใจมากที่ตอนนี้ได้เห็น การออก 1.0

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

  • ฉันคิดว่าระบบแบบ Unison คือ อนาคตของการประมวลผล
    แต่ไม่รู้ว่าอนาคตนั้นจะมาถึงเมื่อไร
    ความงามของระบบแบบนี้คือโครงสร้างพื้นฐาน ข้อมูล และชั้นบริการถูกรวมอยู่ในระบบเดียวกัน
    บางทีอาจเป็นฐานที่ดีกว่าสำหรับ AI coding agents ก็ได้
    แต่รู้สึกว่าแทนที่จะใช้โมเดล VC น่าจะเหมาะกับ การพัฒนาอิสระอย่างยั่งยืน มากกว่า
    ทีมที่ทำโปรเจกต์ระยะยาวแบบนี้ต่อเนื่องได้นี่สุดยอดจริงๆ

  • ฉันจำวันที่ Rúnar บอกว่าจะเริ่ม Unison ได้
    ตอนนั้นคิดว่าเป็นโปรเจกต์ที่จะเปิดพาราไดม์ใหม่แบบเต็มตัว และพอเห็นการออก 1.0 ตอนนี้ก็ภูมิใจมากจริงๆ
    หวังว่าสักวัน Unison จะกลายเป็น ภาษาหลัก ของฉัน

  • อยากให้บนเว็บไซต์ Unison มี benchmark
    ถ้ารู้ลักษณะด้านประสิทธิภาพก็จะพอเดาได้ว่าเหมาะกับงานแบบไหน
    ต่อให้เป็นแค่ตัวเลขง่ายๆ อย่าง การเปรียบเทียบความเร็วในการจัดการคำขอ กับ Django, Express.js, ASP.NET ก็ยังดี
    ไอเดียน่าสนใจนะ แต่ก็หวังว่าจะมีเป้าหมายรันไทม์นอกเหนือจากเว็บด้วย
    สำหรับฉันแล้ว การลองภาษาใหม่กับอะไรอย่าง เครื่องมือ CLI มักง่ายกว่าการใช้กับเว็บโปรเจกต์ขนาดใหญ่

  • ฉันอ้างอิง บทความรีวิว Unison ที่โพสต์ในปี 2023 ด้วย ซึ่งช่วยได้มากทีเดียว

  • ไอเดียน่าสนใจ แต่ Unison เป็นโครงสร้างแบบ all-in-one ที่ต้องรับทั้ง ภาษา + การจัดการซอร์ส + โฮสติ้ง พร้อมกัน
    ถ้าไม่ชอบส่วนใดส่วนหนึ่งของสแตก ก็จะใช้ทั้งหมดได้ยาก
    เพราะงั้นไอเดียแบบนี้น่าจะเผยแพร่ในวงกว้างได้ยากถ้าจะให้คนรับไปตรงๆ

    • Unison สามารถค่อยๆ นำมาใช้ทีละส่วนได้
      คุณภาพของเครื่องมือ ของภาษานั้นสูงมาก และยังรวมเข้ากับระบบเดิมได้ด้วย
      ตัวอย่างเช่น Unison Cloud เขียนด้วย Unison เป็นส่วนใหญ่ แต่บางส่วนก็ใช้ Haskell
      การพูดคุยที่เกี่ยวข้อง: เธรด HN 1, เธรด HN 2
      ฉันคิดว่าการออกแบบหลายเทคโนโลยีให้ทำงานร่วมกันได้อย่างเป็นธรรมชาตินั้นมีคุณค่ามาก
    • มากกว่าจะตัดสินจากความสำเร็จเชิงพาณิชย์ ฉันคิดว่าเกณฑ์ที่น่าสนใจกว่าคือ คุณค่าด้านงานวิจัยทางวิทยาการคอมพิวเตอร์ ที่โปรเจกต์นี้แสดงให้เห็น