Luau – ภาษา scripting ที่อิงกับ Lua ซึ่งเร็ว เล็ก ปลอดภัย และมี gradual typing

 (luau.org)
7 คะแนน โดย GN⁺ 2025-09-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Luau คือ ภาษา scripting แบบฝังตัวที่รองรับ gradual typing ซึ่งรวดเร็วและปลอดภัย โดยแตกแขนงมาจาก Lua 5.1
  • พัฒนาต่อยอดด้าน ประสิทธิภาพ เครื่องมือภาษา และระบบชนิดข้อมูล เพื่อรองรับเกมที่ซับซ้อนและโค้ดเบสขนาดใหญ่บนแพลตฟอร์ม Roblox
  • ต่างจาก Lua ปกติ ตรงที่มี ความสามารถด้าน sandboxing และถูกออกแบบมาเพื่อให้โค้ดที่มีสิทธิ์ต่างกันสามารถรันควบคู่กันได้
  • ไวยากรณ์เข้ากันได้กับ Lua 5.1 แต่มี ส่วนขยายไวยากรณ์เพิ่มเติม และ เครื่องมือวิเคราะห์ (linter, type checker) เพื่อยกระดับคุณภาพโค้ด
  • ด้วยการปรับแต่งประสิทธิภาพ ไบต์โค้ดแบบปรับแต่งเอง และการรองรับ JIT ทำให้ตั้งเป้าความเร็วในการรันระดับ LuaJIT และมีศักยภาพสำหรับการใช้งานในสภาพแวดล้อมแบบฝังตัวที่หลากหลายนอกเหนือจาก Roblox

Motivation (ที่มาและแรงจูงใจ)

  • ราวปี 2006 Roblox ได้นำ Lua 5.1 มาใช้เป็นภาษา scripting สำหรับเกม
  • เมื่อเวลาผ่านไป ระดับความซับซ้อนของเกมบน แพลตฟอร์ม Roblox สูงขึ้นและขนาดทีมใหญ่ขึ้น จึงมีการปรับปรุงทั้งตัวภาษาและ implementation อย่างมากเพื่อก้าวข้ามข้อจำกัดของ Lua เดิม
  • ตามการเติบโตของแพลตฟอร์ม มีการลงทุนอย่างมากในด้านการปรับแต่งประสิทธิภาพ ความเป็นมิตรต่อผู้ใช้ และการพัฒนาเครื่องมือที่เกี่ยวข้องกับภาษา
  • โดยเฉพาะเมื่อถึงปี 2020 การดูแล โค้ดเบสขนาดใหญ่ ที่มีมากกว่า 1 ล้านบรรทัด ทำให้ตระหนักว่าการนำระบบ gradual typing มาใช้เป็นสิ่งจำเป็น
  • จากความต้องการเหล่านี้ Roblox จึงพัฒนา Luau ซึ่งเป็นภาษาที่แตกแขนงจาก Lua โดยมีคุณสมบัติทั้งเร็ว เล็ก ปลอดภัย และสามารถค่อย ๆ นำ type มาใช้ได้
  • รายละเอียดเพิ่มเติมมีอยู่ในเอกสาร Why Luau

ภาพรวมของ Luau

  • Luau คือ ภาษา scripting แบบฝังตัว ที่อิงกับ Lua 5.1
    • ให้ runtime ที่รวดเร็วและน้ำหนักเบา
    • รองรับระบบ gradual typing ทำให้สามารถทำ การวิเคราะห์ทั้งแบบ dynamic และ static ควบคู่กันได้
  • ผสานรวมอยู่ใน Roblox Studio และสามารถเปิด strict mode ได้ด้วยแฟล็ก --!strict
  • นักพัฒนาสามารถดูเอกสารที่เชื่อมโยงกับ Roblox ได้ที่ Luau Creator Docs

Sandboxing (ความสามารถด้านแซนด์บ็อกซ์)

  • Luau จำกัด standard library ที่เปิดให้ใช้งาน และมี ความสามารถด้าน sandboxing เพิ่มเติม
  • ทำให้สามารถรัน โค้ดที่ไม่มีสิทธิ์พิเศษซึ่งเขียนโดยนักพัฒนาทั่วไป และ โค้ดสิทธิ์พิเศษภายในแพลตฟอร์ม แบบขนานกันได้อย่างปลอดภัย
  • ด้วยเหตุนี้ สภาพแวดล้อมการรันจึงแตกต่างจาก Lua ปกติ
  • ดูรายละเอียดได้ใน คำอธิบาย Sandbox

Compatibility (ความเข้ากันได้)

  • พยายามคง ความเข้ากันได้ย้อนหลังกับ Lua 5.1 ให้มากที่สุด และนำความสามารถบางส่วนจากเวอร์ชันหลังจากนั้นมาด้วย
  • อย่างไรก็ตาม Luau ไม่ได้รับทุกการตัดสินใจด้านการออกแบบของ Lua มาใช้ทั้งหมด แต่สะท้อนกรณีการใช้งานและข้อจำกัดเฉพาะของ Roblox
  • สถานะการรองรับฟีเจอร์จาก Lua เวอร์ชันหลัง 5.1 ดูได้ใน เอกสาร Compatibility

Syntax (ไวยากรณ์)

  • เข้ากันได้เต็มรูปแบบกับไวยากรณ์ของ Lua 5.1
  • เพิ่มเติมด้วย ส่วนขยายไวยากรณ์ที่ทันสมัยและคุ้นเคย เพื่อเพิ่มความสะดวกในการพัฒนา
  • ดูไวยากรณ์ทั้งหมดได้ใน เอกสาร Syntax

Analysis (เครื่องมือวิเคราะห์)

  • มี เครื่องมือวิเคราะห์สคริปต์ เพื่อช่วยให้เขียนโค้ดได้ถูกต้อง

  • องค์ประกอบได้แก่:

    • Linter: ตรวจจับข้อผิดพลาดทั่วไป
    • Type Checker: ตรวจสอบชนิดข้อมูล

  • สามารถรันได้ด้วยเครื่องมือ CLI luau-analyze

  • กฎการ lint ดูได้ที่ เอกสาร Lint และแนวทางการตรวจ type ดูได้ที่ เอกสาร Typecheck

Performance (ประสิทธิภาพ)

  • มีทั้ง ฟรอนต์เอนด์แบบกำหนดเอง ที่รวม parser, linter และ type checker ไว้ด้วยกัน รวมถึง ไบต์โค้ด อินเทอร์พรีเตอร์ และคอมไพเลอร์ที่ปรับแต่งมาแล้ว
  • ในบางกรณีให้ประสิทธิภาพที่สามารถแข่งขันกับอินเทอร์พรีเตอร์ LuaJIT ได้
  • รองรับ คอมไพเลอร์ JIT แบบเขียนเอง บนแพลตฟอร์ม x64 และ ARM64 ซึ่งสามารถเพิ่มประสิทธิภาพให้บางโปรแกรมได้อย่างมาก
  • มีการปรับแต่ง runtime อย่างต่อเนื่องและเขียนบางส่วนใหม่เพื่อเพิ่มประสิทธิภาพ
  • รายละเอียดเชิงลึกด้านประสิทธิภาพมีอยู่ใน เอกสาร Performance

Libraries (ไลบรารี)

  • ตัวภาษาเองเป็น superset แบบสมบูรณ์ของ Lua 5.1
  • ใน standard library มีการนำบางฟังก์ชันออก และเพิ่มฟังก์ชันใหม่บางส่วน
  • เมื่อนำไปฝังในแอปพลิเคชัน ก็สามารถเข้าถึง ไลบรารีส่วนขยายเฉพาะแอป ได้ด้วย
  • ดูเอกสารไลบรารีทั้งหมดได้ใน เอกสาร Library

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

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

 
GN⁺ 2025-09-23
ความคิดเห็นจาก Hacker News
  • มีประสบการณ์ใช้ Lua และ LuaJIT ใน Lumix Engine แล้วเปลี่ยนมาใช้ Luau เพราะระบบ type แต่ก็รู้สึกว่าใช้งานนอกโปรเจ็กต์ Roblox ได้ยาก เอกสารไม่ดีและแทบไม่มีคอมมูนิตี้เลยจึงไม่ช่วยในการแก้ปัญหา เมื่อเทียบกับ Lua หรือ LuaJIT แล้วขนาดใหญ่กว่า ทำให้คอมไพล์ช้าลง 7 เท่า การจัดการ async ของ API ก็ในทางปฏิบัติกลับถูกบล็อกแบบ synchronous และยังมีความไม่สะดวกหลายอย่าง เช่น ใช้ STL รวมถึงเจอบั๊กด้าน analysis และ LSP บ่อย จึงกำลังคิดว่าจะหาทางเลือกอื่นดีหรือไม่
    • ทีม Roblox กำลังให้ความสำคัญกับการทำให้ Luau ใช้งานนอก Roblox ได้ง่ายขึ้นในอนาคต มีการใช้งานได้ดีแล้วในหลายแห่ง เช่น Remedy Entertainment (Alan Wake 2), Digital Extremes (Warframe), GIANTS Software (Farming Simulator 25) ที่ผ่านมาการลงทุนและการซัพพอร์ตยังเน้นอยู่ภายใน Roblox แต่ต่อจากนี้กำลังพัฒนา Lute ซึ่งเป็น runtime แบบ standalone สำหรับงานทั่วไป และตั้งใจจะสร้างเครื่องมือนักพัฒนาที่อิง Luau เพิ่มเติมเพื่อขยาย ecosystem ตอนนี้ยังอยู่ระยะเริ่มต้น แต่ก็กำลังลงทุนอย่างจริงจังเพื่อรองรับการใช้งานภายนอกและกรณีใช้งานที่หลากหลาย โดยเชื่อว่าการดึงผู้ใช้และ use case ที่หลากหลายเข้ามาเป็นสิ่งสำคัญต่อการเติบโตอย่างแข็งแรงของ Luau
    • กำลังใช้ Luau กับโค้ดเกมทั้งชุดของ Unity (มากกว่า 60,000 บรรทัด) อยากให้เอกสาร โดยเฉพาะส่วนการเชื่อมต่อแบบ custom ได้รับการปรับปรุงมากขึ้น และยังรู้สึกว่าระบบ type ใหม่กับ LSP เข้ากันได้ไม่ค่อยดี หลังจาก zeux ออกจากทีมก็แอบกังวลเรื่องทิศทางระยะยาวอยู่บ้าง แต่ชอบประสบการณ์การพัฒนาโดยรวมมาก โค้ด Luau hot reload ได้แทบจะทันทีแม้ตอนเกมกำลังรันอยู่ และโปรเจ็กต์ C++ ก็ยังคอมไพล์ได้เร็ว อีกทั้งยังชอบที่มี sandbox environment ให้เพื่อรองรับ modding ด้วย คอมมูนิตี้ Discord อย่างเป็นทางการก็ค่อนข้างคึกคักพอสมควร
    • มีคนบอกว่าคอมไพล์ช้า เลยสงสัยว่าถ้าเป็นภาษาสคริปต์ปกติก็ไม่น่าต้องคอมไพล์โค้ดหรือเปล่า หรือว่าหมายถึงการคอมไพล์ตัว Luau VM เอง
  • น่าสนใจมากที่ Roblox กำลังพัฒนา Luau runtime สำหรับเดสก์ท็อปในสไตล์ Node.js: https://github.com/luau-lang/lute
    • มี Luau runtime ที่สมบูรณ์กว่าชื่อ Lune อยู่แล้ว ใช้มันกับ build script และงานอัตโนมัติของไฟล์ Roblox place และสำหรับจุดประสงค์การใช้งานของตนก็ทำงานได้น่าพอใจเพียงพอ
    • มี standalone Luau runtime อีกตัวคือ Lune
  • Luau ดูซับซ้อนกว่า Lua มาก เมื่อดูจากตัวโค้ด Luau มี C++ 120,000 บรรทัด ส่วน Lua 5.1 มี C 14,000 บรรทัด คิดว่าถ้ามีระบบ type แบบ gradual หรือ static ความซับซ้อนเพิ่มขึ้นก็คงหลีกเลี่ยงไม่ได้ ถ้ามีระบบ type ที่ค่อนข้างครบถ้วน สุดท้ายก็ย่อมใหญ่กว่าภาษาสคริปต์แบบ dynamic อยู่ดี
    • Lua (และ Luau ก็ในระดับหนึ่ง) ไม่ใช่ภาษาที่เล็กเพราะจำนวนบรรทัดโค้ด แต่เล็กในแง่ที่ตัวภาษาเรียนรู้ได้ไม่ยาก runtime ที่ใช้รันก็ไม่ได้พึ่ง Analysis ทั้งหมด ใน Analysis มีระบบ type แบบสมบูรณ์อยู่สองชุด และในช่วง 3 ปีที่ผ่านมาได้พัฒนาระบบ type ใหม่เพื่อแก้ข้อจำกัดเชิงพื้นฐาน ตอนนี้ระบบเก่าก็กำลังจะถูกถอดออก ซึ่งจะลดโค้ดได้ราว 30,000 บรรทัด
    • ฉันไม่คิดว่า Lua และ Luau เป็นภาษาที่เล็กหรือเรียบง่าย และความซับซ้อนก็อาจไม่จำเป็นเสมอไป กำลังทำภาษาใหม่ที่เรียบง่ายแต่แสดงออกได้ดีชื่อ Bau พร้อมพัฒนา VM สไตล์ Lua ด้วย ภาษาขนาดเล็กแบบนี้ก็เป็นหัวข้อใน Reddit อยู่บ่อย Bau, Bau VM, r/ProgrammingLanguages
    • static typing หรือ gradual typing เพิ่มความซับซ้อนจริง แต่เพิ่มไม่มากอย่างที่คิด บางครั้งภาษาสคริปต์แบบ dynamic ยังซับซ้อนกว่าด้วยซ้ำ ตัวตรวจ type แบบ Hindley–Milner นั้นทำได้ในโค้ดเพียงหน้าเดียว ส่วนความซับซ้อนระดับ 2,000 หน้าที่พูดถึงกันอยู่นี้รู้สึกว่าเกินไป H–M นั้นสมบูรณ์ได้แม้ไม่รองรับ higher-order function, generic (parametric polymorphism) หรือ null pointer และยังทำ inference ได้ทั้งระบบ ขยายต่อได้ และแค่พื้นฐานก็ยังทรงพลังกว่าระบบ type ของ C หรือ Java 1.7 มาก
    • เคยเขียน type checker สำหรับ Lua เองและอ่านซอร์สมามากแล้ว 14,000 บรรทัดของ Lua นั้นมีความหนาแน่นของโค้ดสูงมาก ถ้าเขียนด้วยสไตล์ทั่วไประดับปกติจะกลายเป็นประมาณ 30,000-40,000 บรรทัด หมายความว่า Lua ไม่ได้เล็กโดยเนื้อแท้ แต่ถูกเขียนมาอย่างกระชับมาก
    • ถ้าแจกแจงจำนวนบรรทัดจากการวิเคราะห์ด้วย tokei ให้ละเอียดขึ้น Analysis directory มี C++ 62,000 บรรทัด, C header 9,200 บรรทัด, Ast มี C++ 8,400 บรรทัด, CodeGen C++ 21,000 บรรทัด เป็นต้น ส่วน Lua 5.1 มีโค้ด C ทั้งหมดใน src 11,000 บรรทัด และ header 1,900 บรรทัด
  • สงสัยว่าต่างกันอย่างไรระหว่าง Teal กับ Luau ทั้งคู่แนะนำตัวว่าเป็น "ภาษา Lua dialect ที่มี static type" เลยอยากเปรียบเทียบ https://teal-language.org/
    • Teal คอมไพล์ไฟล์ Teal ไปเป็น Lua ทำให้มีทั้งข้อดีข้อเสียแบบเดียวกับความสัมพันธ์ระหว่าง JS กับ TS ส่วน Luau มี runtime ของตัวเองที่เป็น superset ของ Lua ซึ่งไม่ได้แค่เพิ่มระบบ type แต่ยังปรับปรุงประสบการณ์การพัฒนาโดยรวมด้วย ดังนั้นทั้งสองจึงค่อนข้างต่างกัน Teal มีข้อดีตรงที่ใช้ Lua ได้ทุกที่ ขณะที่ Luau รันได้เฉพาะบน runtime ของ Luau แต่ไม่มีขั้นตอนคอมไพล์แยก จึงให้ประสบการณ์ใช้งานที่ดีกว่าสำหรับนักพัฒนา และยังใช้ประโยชน์จากข้อมูล type ได้โดยไม่ทำหายไป
    • Teal ถูก transpile ไปเป็น Lua แต่ Luau เป็น fork ของ Lua จึงเปลี่ยนแปลงได้กว้าง ทั้งด้านประสิทธิภาพของ interpreter เอง ความปลอดภัย และการขยาย syntax Roblox เป็นบริษัทใหญ่มากจนมูลค่าตลาดแตะระดับ 100 พันล้านดอลลาร์ และมีนักพัฒนาเฉพาะทางประจำอยู่หลายคน
    • Luau ไม่ใช่แค่ "Lua ที่เพิ่ม type" แต่ทุ่มน้ำหนักมากกับระบบ type แบบ gradual และ type inference พร้อมทั้งค่อย ๆ ปรับปรุงตัวภาษาเองด้วย ออกแบบโดยเน้นประสบการณ์นักพัฒนาและการรองรับเครื่องมือ แม้จะใส่ใจเรื่องขนาดไบนารีด้วย แต่ไม่ได้ให้ความสำคัญสูงสุดกับความเรียบง่ายแบบเข้มงวดเหมือน Lua จุดโฟกัสจึงไม่ใช่การผูกโปรเจ็กต์ C ขนาดใหญ่เข้ากับ Lua เท่านั้น แต่เป็นการทำให้นักพัฒนาได้รับประสบการณ์ที่ดีจากตัวภาษาโดยตรง
  • เสียดายที่ Lua พัฒนาไปโดยรักษาความเข้ากันได้กับอดีตไว้ไม่ดีพอ ช่วงปลายยุค 2000 หลายโปรเจ็กต์รวมถึง Roblox เลือกใช้ Lua 5.1 และตอนนี้ Lua ไปถึง 5.4 แล้ว แต่ความเข้ากันได้กับเวอร์ชันเก่ากลับไม่ดีนัก LuaJIT ก็รองรับแค่ 5.1 สถานการณ์คล้าย Python 2.x/3.x แต่ดูเหมือนชุมชน Lua ส่วนใหญ่ยังคงใช้ 5.1 ต่อไป
    • ในความเป็นจริงหนักกว่านั้นอีก ทั้ง luau และ luaJIT ก็พัฒนาไปคนละทางกับโปรเจ็กต์ lua ทางการ จนตอนนี้เข้ากันได้ไม่สมบูรณ์ในรายละเอียด ทั้งหมดแตกออกมาจาก Lua 5.1 แต่ตอนนี้ให้ความรู้สึกเหมือนไม่มีมาตรฐานกลางอย่างเป็นทางการแล้ว
    • ความต่างสำคัญคือชุมชน Lua ไม่ค่อยออกมาวิพากษ์เรื่องการรักษา backward compatibility อย่างรุนแรง จึงทำให้เขียนโค้ดแยกตามเวอร์ชันต่าง ๆ ได้ค่อนข้างง่าย
    • หาสถิติอย่างเป็นทางการได้ยาก แต่จากความรู้สึกส่วนตัว ผู้ใช้ 5.1 และ 5.2 น่าจะมากกว่า 5.4 และดูเหมือน 5.3 ก็ยังแซงไม่ได้ ส่วน LuaJIT แม้มีคนสนใจมาก แต่ในการใช้งานจริงกลับไม่ค่อยพบเห็นบ่อยนัก
    • LuaJIT มีฟีเจอร์จาก Lua เวอร์ชันใหม่กว่า (5.2, 5.3) อยู่บางส่วน และยังมีฟีเจอร์เพิ่มอีกด้วย https://luajit.org/extensions.html
  • สิ่งที่น่าสนใจที่สุดคือ Luau interpreter บางกรณีทำผลงานได้สูสีกับ LuaJIT หน้า performance อธิบายไว้ดีมากและทำให้รู้สึกถึงศักยภาพทางวิศวกรรมของ Roblox https://luau.org/performance
  • พอลูกอายุ 13 ปีเริ่มสนใจ Roblox Studio ก็เลยได้รู้จัก Luau และลองเข้าไปดูที่ luau.org ด้วย งานวิศวกรรมของ Roblox น่าประทับใจจริง ๆ
    • Arseny Kapoulkine เป็นวิศวกรที่ยอดเยี่ยม ควรติดตามบล็อกหรือโซเชียลของเขา นอกจาก luau และเอนจินเรนเดอร์ของ Roblox แล้ว เขายังเป็นผู้สร้าง meshoptimizer ซึ่งแทบเป็นไลบรารีที่คนในวงการกราฟิกต้องเจอ และ volk ก็ยังถูกรวมอยู่ใน Vulkan SDK ด้วย
  • Second Life กำลังย้ายจาก Linden Scripting Language เดิมมาเป็น Luau เดิมใช้การคอมไพล์บน Mono แต่ Mono ไม่ได้รับการดูแลต่อแล้วจึงต้องการภาษาใหม่ ไม่ใช่แค่รองรับ Luau เท่านั้น แต่ยังเปลี่ยนให้คอมไพเลอร์ LSL เดิม target ไปยังเอนจินรัน Luau ด้วย ประสิทธิภาพก็ดีขึ้นเล็กน้อย Second Life เป็นสภาพแวดล้อมเฉพาะที่มีสคริปต์แบบ event-driven หลายแสนตัวรันอยู่บนเซิร์ฟเวอร์ จึงจัดการทรัพยากรได้ยาก ถ้าโปรแกรมที่ไม่ได้ใช้งานกินเวลา 1 ไมโครวินาทีต่อเฟรม พอสะสมแล้วก็เป็นปัญหาใหญ่ได้
    • ตอนที่เปิด Luau เบต้าได้ลองใช้ด้วยตัวเองและรู้สึกได้ว่าประสิทธิภาพดีขึ้นอย่างมากเมื่อเทียบกับระบบ Mono เดิม โดยเฉพาะความเร็วในการตรวจสคริปต์ตอนกด Save ที่ลดจาก 10 วินาทีเหลือแทบจะทันที ทำให้ประสิทธิภาพการพัฒนาดีขึ้นมาก แต่ก็อยากได้ helper function อย่าง CreateThread(fn), Wait(ms) สำหรับจัดการ coroutine แบบสะดวกเหมือนใน FiveM รวมถึงฟีเจอร์ Await/Promises ด้วย (ตัวอย่าง Luau Promise implementation) ใน FiveM ตัว wrapper แบบนี้ช่วยให้จัดการการ optimize สคริปต์และ coroutine ได้ง่ายขึ้น ตัวอย่าง Lua scheduler ของ FiveM
    • หลังเปลี่ยน VM แล้ว สิ่งที่เห็นได้ชัดทันทีคือ overhead เดิมจำนวนมากอยู่ที่ scheduling, context switching และการ implement ฟังก์ชันไลบรารี Luau รองรับ preemptive scheduling ได้อย่างเป็นธรรมชาติตามการออกแบบ ทำให้การประสานงานผ่าน glue code แบบง่ายทำได้สะดวกกว่ามาก การจัดการสิ่งนี้บน VM มีต้นทุนต่ำกว่าและทำได้ง่ายกว่าการแปลงเป็น state machine ในระดับ AST หรือ bytecode มาก ส่วน overhead ระดับไมโครวินาทีของโปรแกรมที่ idle อยู่ก็เป็นสิ่งที่ scheduler ควร optimize เช่นกัน
  • เสน่ห์แบบมินิมอลของ Lua เดิมถูกลดทอนลงไปบ้างเพราะ type inference แต่ก็เป็นการแลกกับ type safety จึงมีทั้งข้อดีและข้อเสีย อย่างไรก็ตาม พอประกาศ --!strict แล้วกลับพบว่าถึงจะมีการละเมิด type ชัดเจน โค้ดก็ยังรันได้โดยไม่มี error หรือ warning ใด ๆ เลย จึงรู้สึกตกใจเพราะไม่เป็นไปตามที่คาดหวัง
    • ตอนนี้ระบบ type ของ Luau ยังไม่ใช่แบบ "บังคับใช้ (strict)" สามารถรันโค้ดได้โดยไม่ตรวจ type และถ้ารันตรงผ่านเดโมหรือ executable luau ก็จะไม่มีการตรวจ type ถ้าในสภาพแวดล้อมแบบ embedded บังคับให้ทุกโค้ดผ่านการตรวจ type ก่อนคอมไพล์ ก็จะได้ประสบการณ์ตามที่คาดไว้คือจับ type error ได้จริง นี่เป็นการออกแบบที่หลีกเลี่ยงไม่ได้เพราะต้องย้ายโค้ด Lua 5.1 หลายล้านบรรทัดมาเป็น Luau ในคราวเดียว
  • อยากได้ Typed Lua มาตลอด แต่การทำ type checker และ LSP ให้สมบูรณ์กับภาษาที่เป็น dynamic นั้นยากมาก แต่ละภาษาก็มีปัญหาเรื่อง structural typing คล้าย ๆ กัน (คล้ายกับที่เจอใน TypeScript) เลยสงสัยว่าถ้านำเอนจิน TypeScript มาใช้ซ้ำ โดยแปลงโค้ด Luau บางส่วนไปเป็น TypeScript เพื่อตรวจด้วย tsc แล้วค่อย map error/ผลลัพธ์กลับมาเป็น Luau จะช่วยให้สร้าง type checker ที่เร็วสำหรับภาษากลุ่ม dynamic ได้หรือไม่
    • คล้ายกับที่ LLVM เป็น common IR สำหรับคอมไพเลอร์ อาจเป็นไปได้ที่จะใช้ TypeScript type system เป็น backend กลางในฐานะ "ภาษากลาง" สำหรับระบบ type ฉันไม่ได้ชอบภาษา dynamic มากนัก แต่ถ้าได้การตรวจ type และการรองรับเครื่องมือระดับ TypeScript ก็น่าจะสนใจขึ้นมาก ถ้าบางส่วนทำไม่ได้ก็ยอมรับได้ เพราะนั่นคือแก่นของ gradual typing ถ้ามี TypeScript type system มาอยู่บน Lua runtime ก็ตั้งใจว่าจะลองใช้แน่นอน และก็ติดตามทิศทางของ Luau อยู่มาก
    • Luau มี Luau Language Server ที่ยอดเยี่ยมอยู่แล้ว ทำให้ใน vscode, nvim, zed ฯลฯ ได้ทั้งการวินิจฉัย, autocomplete และการตรวจ type แบบเข้มงวดที่ดีมาก ประสบการณ์การพัฒนาดีกว่าที่เคยรู้สึกใน Ruby หรือ Python มาก ฉันใช้ Luau ทั้งกับ shell scripting และงานโปรแกรมทั่วไป และยังทำ runtime สไตล์ node ของตัวเองชื่อ seal ด้วย ส่วนฝั่งนักพัฒนา Roblox เห็นว่ามักใช้ Lune ที่นิยมกว่าสำหรับ CI/CD และ testing
    • ถ้าจะใช้ TypeScript เพื่อใส่ type ให้ภาษากลุ่ม dynamic ครอบคลุมทุกมุม ระบบจะซับซ้อนเกินไป จึงคิดว่าการทำแบบ Rescript หรือ Gleam ที่จำกัดบางส่วนของภาษาเป้าหมาย แล้วใช้ระบบ type แบบ Hindley–Milner จะดีกว่า ระบบ type แบบ HM มีทั้งประสบการณ์ใช้งานจริงและทฤษฎีรองรับมานาน จึงทั้งแข็งแรงและใช้ได้จริง ส่วนตัวแปลกใจที่ไม่มีโปรเจ็กต์ภาษาเล็กสาย ML ที่ปล่อยโค้ดออกมาเป็น lua มากนัก ถ้า Gleam รองรับ backend เป็น Lua ก็น่าจะเข้ากันได้ดีมาก
    • มีโปรเจ็กต์ที่มีอยู่แล้วคือ TypeScriptToLua เคยลองใช้กับ Love2D แล้วรู้สึกว่าใช้ได้ดีพอสมควร