Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

ยินดีต้อนรับสู่ Rust Feed — แหล่งรวบรวมบทความภาษา Rust ที่โพสต์ใน Facebook Rust Dev Community ซึ่งนำมาจัดหมวดหมู่ตามหัวข้อเพื่อให้ค้นหาได้ง่าย (การค้นหาขอให้ใช้คีย์เวิร์ดภาษาอังกฤษในการค้นหานะครับ)

เนื้อหาแบ่งตามหัวข้อดังนี้

  • Case Study: กรณีศึกษาจากโปรเจกต์จริง
  • Deep Dive: เจาะลึกสถาปัตยกรรมและแนวคิดสำคัญ
  • Rust Blockchain: Rust กับเทคโนโลยี Blockchain
  • Rust Core: แนวคิดหลักของภาษา Rust
  • Rust Crates: ไลบรารีและ crates ที่น่าสนใจ
  • Rust Games: การพัฒนาเกมด้วย Rust
  • Rust Hacker: เทคนิคขั้นสูงและ low-level programming
  • Rust Project: ไอเดียและโปรเจกต์ตัวอย่าง
  • Rust Research: งานวิจัยและบทความเชิงวิชาการ
  • Rust Tools: เครื่องมือที่ช่วยในการพัฒนา
  • Rust Update: ข่าวสารและอัปเดตล่าสุด
  • Rust Web: การพัฒนาเว็บด้วย Rust

Case Study

เมื่อ Vite 8 เดิมพันอนาคตของ Web Tooling ด้วยสถาปัตยกรรมแบบที่ขับเคลื่อนด้วย Rust (Rolldown + Oxc)

📅 วันที่เผยแพร่: 2026-03-21

เพิ่งมีการประกาศเปิดตัว Vite 8 อย่างเป็นทางการเมื่อเร็วๆ นี้ (12 มีนาคม 2026) มองเผินๆ อาจจะดูเหมือนเป็นการอัปเดตเครื่องมือฝั่ง Frontend ธรรมดาๆ แต่ถ้ามองลึกลงไปในระดับสถาปัตยกรรม นี่คือหนึ่งในกรณีศึกษาที่น่าสนใจมากครับ เพราะมันพิสูจน์ให้เห็นว่า Rust ไม่ได้มีดีแค่ความเร็ว แต่มันคือภาษาที่เข้ามาแก้ปัญหาคอขวดทางสถาปัตยกรรมที่เรื้อรังมาอย่างยาวนาน

ปัญหาของสถาปัตยกรรมแบบเดิม (Dual-Bundler)

ย้อนกลับไปในอดีต ความสำเร็จของ Vite เกิดจากการใช้สถาปัตยกรรมแบบ “Dual-bundler” คือใช้ esbuild (เขียนด้วย Go) เพื่อความเร็วในการคอมไพล์ตอน Development และใช้ Rollup (เขียนด้วย JavaScript) สำหรับการทำ Optimization ในฝั่ง Production

แม้แนวทางนี้จะเวิร์ค แต่มันแลกมาด้วย Technical Debt มหาศาล การมี Pipeline การแปลงโค้ดถึงสองชุด หมายความว่าทีมงานต้องเขียน “Glue code” จำนวนมากเพื่อเชื่อมระบบ Plugin ทั้งสองฝั่งให้ทำงานตรงกัน นำไปสู่ปัญหา Edge cases และความไม่สอดคล้องกันของการจัดการ Module ที่สะสมพอกพูนตามกาลเวลา

ทางออกด้วย Rolldown และ Rust

ทางออกของปัญหานี้ไม่ได้อยู่ที่การปรับจูนโค้ดเดิม แต่คือการรื้อโครงสร้างใหม่ทั้งหมดด้วย Rolldown ซึ่งเป็น Bundler ตัวใหม่ที่เขียนด้วย Rust (พัฒนาโดยทีม VoidZero)

การเข้ามาของ Rust ในครั้งนี้ไม่ใช่แค่การทำ Rewrite it in Rust (RIIR) เพื่อเอาความเร็วแบบ Native speed เท่านั้น แต่เป้าหมายหลักคือ การสร้าง Unified Toolchain หรือการรวมศูนย์เครื่องมือทั้งหมดให้เป็นหนึ่งเดียว

เมื่อ Vite 8 ทำงานร่วมกับ Rolldown และคอมไพเลอร์ที่เขียนด้วย Rust อย่าง Oxc สิ่งที่เกิดขึ้นคือการจัดการหน่วยความจำและการส่งผ่านข้อมูลระดับลึกที่แนบเนียนอย่างไร้รอยต่อ ตั้งแต่ขั้นตอน Parsing, Resolving ไปจนถึง Transforming และ Minifying การที่ระบบทั้งหมดอยู่ในสภาพแวดล้อมของ Rust ทำให้ทีมพัฒนาสามารถทำ Optimization ระดับลึกที่เมื่อก่อนเป็นไปไม่ได้ เช่น การนำ Semantic Analysis ของ Oxc มาวิเคราะห์โครงสร้างเพื่อทำ Tree-shaking ใน Rolldown ได้อย่างหมดจดและแม่นยำยิ่งขึ้น

ผลลัพธ์ที่ก้าวกระโดด

ผลลัพธ์ที่ได้นั้นก้าวกระโดดอย่างชัดเจน:

  • ความเร็ว: Rolldown สามารถทำความเร็วได้มากกว่า Rollup เดิมถึง 10-30 เท่า (เทียบเท่าระดับของ esbuild)
  • Production Build: มีกรณีศึกษาจากโปรเจกต์ขนาดใหญ่อย่างแอปพลิเคชัน Linear ที่เวลาในการบิลด์ Production ลดลงจาก 46 วินาที เหลือเพียง 6 วินาทีเท่านั้น (หรือบริษัทอย่าง Beehiiv ที่ลดเวลาบิลด์ได้ถึง 64%)
  • ความเข้ากันได้: ในขณะที่ยังคงความเข้ากันได้ (Compatibility) กับ Plugin API ของ Rollup เดิมแทบจะ 100%

อนาคตที่น่าจับตาสำหรับชาว Rust Developer

สิ่งที่น่าสนใจที่สุดสำหรับชาว Rust Developer คือ แผนการในอนาคตที่สะท้อนให้เห็นถึงการแก้ปัญหาเรื่อง Serialization/Deserialization Overhead ระหว่าง Rust และ Node.js อย่างถึงแก่น ในเอกสารอ้างอิงได้ระบุถึงฟีเจอร์ที่กำลังพัฒนา เช่น:

  • Raw AST Transfer: ที่จะอนุญาตให้ Plugin ฝั่ง JavaScript สามารถเข้าถึง Abstract Syntax Tree (AST) ที่ถูกสร้างขึ้นจากฝั่ง Rust ได้โดยมี Overhead ในการแปลงข้อมูลต่ำที่สุด
  • Native MagicString transforms: ที่เป็นกระบวนทัศน์ใหม่ของการเขียน Plugin โดยให้ Logic การทำงานอยู่ฝั่ง JavaScript แต่ผลักภาระงานประมวลผลการจัดการ String ที่หนักหน่วงไปให้ฝั่ง Rust เป็นคนจัดการแทน

บทสรุป

Vite 8 จึงเป็นเหมือนการตอกย้ำว่า ในยุคถัดไปของการสร้างเครื่องมือสำหรับนักพัฒนา การผสมผสานระหว่าง High-level API (JS/TS) เข้ากับ Low-level Performance & Memory Control (Rust) คือสถาปัตยกรรมที่ยั่งยืนที่สุดก็เป็นได้ครับ

Credit & Reference:

  1. Vite 8.0 is out!
  2. vite GitHub repo
  3. rolldown GitHub repo
  4. oxc GitHub repo

การใช้ Rust หั่นโค้ดทิ้ง 90% ก่อนป้อนให้ LLM

📅 วันที่เผยแพร่: 2026-03-08

การทำงานร่วมกับ AI Coding Agents ข้อจำกัดหนึ่งที่เรามักเจอกันคือเรื่องของ Context Window แม้ว่าปัจจุบันโมเดลจะรองรับได้ถึงระดับหลักแสนหรือล้าน Token แต่ในทางปฏิบัติ การยัดโค้ดทั้งหมดลงไปกลับไม่ได้ทำให้ผลลัพธ์ดีขึ้นเสมอไป สมมติว่าเรามีโปรเจกต์ TypeScript ขนาด 80 ไฟล์ ซึ่งกินพื้นที่ประมาณ 63,000 Tokens ปัญหาที่เกิดขึ้นคือเมื่อบริบทยาวเกินไป โมเดลจะเริ่มเกิดอาการ “Attention Drop” การตอบสนองช้าลง และตรรกะการให้เหตุผลเริ่มผิดเพี้ยน นั่นเป็นเพราะโค้ดกว่า 80% ในโปรเจกต์คือ Implementation details อย่างเช่น การวนลูป, การจัดการ Error, หรือไส้ในของฟังก์ชัน CRUD ทั่วไป ซึ่งเป็น “Noise” ที่โมเดลไม่ได้ต้องการเลยเวลาที่เราถามถึงภาพรวมของ Architecture หรือการเชื่อมต่อระหว่าง Service

Skim เครื่องมือสกัดโครงสร้างโค้ดด้วย Rust

เพื่อแก้ปัญหานี้ Dean Sharon ได้พัฒนาเครื่องมือขึ้นมาตัวหนึ่งชื่อว่า Skim โดยเลือกใช้ Rust เป็นแกนหลักในการพัฒนา ตัวโปรเจกต์ถูกออกแบบมาให้เป็นเสมือน Streaming Reader คล้ายกับคำสั่ง cat ใน Unix แต่มีความฉลาดในระดับโครงสร้างภาษา หน้าที่ของมันคือการสกัดเอาเฉพาะแก่นของโค้ด เช่น โครงสร้างคลาส, Signatures, และ Type definitions ออกมา แล้วแทนที่ไส้ในของฟังก์ชันด้วยคอมเมนต์ /* ... */ ผลลัพธ์คือ มันสามารถลดจำนวน Token ลงได้มหาศาล อย่างโหมด Types สามารถลดขนาดโปรเจกต์ 63k Tokens ให้เหลือเพียง 5k Tokens ได้ (ลดไปกว่า 91%) ทำให้เราสามารถโยนโครงสร้างทั้งหมดเข้า LLM ได้ใน Prompt เดียว โดยยังมีพื้นที่เหลือให้โมเดลได้ประมวลผลตรรกะได้อย่างเต็มประสิทธิภาพ

สถาปัตยกรรม AST และการจัดการ Memory

แต่สิ่งที่ทำให้โปรเจกต์นี้น่าสนใจสำหรับชาว Rust คือสถาปัตยกรรมเบื้องหลังและการจัดการ Memory อย่างแยบคาย การทำงานระดับโครงสร้างภาษาจำเป็นต้องพึ่งพากระบวนการ Parse ระดับ AST (Abstract Syntax Tree) ซึ่งโปรเจกต์นี้เลือกใช้ tree-sitter (Incremental parser แบบเดียวกับที่ Editor สมัยใหม่ใช้) การออกแบบสถาปัตยกรรมภายในถูกจัดวางด้วย Strategy Pattern ผ่านฟีเจอร์ที่แข็งแกร่งอย่าง enum และ Pattern Matching ของ Rust โค้ดจะถูกแยกสายการทำงานตามประเภทของภาษาอย่างชัดเจน ตัวอย่างที่น่าสนใจคือ การจัดการไฟล์ JSON จะไม่ถูกโยนเข้า tree-sitter เพราะมันถือเป็น Data ไม่ใช่ Code ตัวโปรเจกต์จึงแยกให้ JSON วิ่งผ่าน serde_json โดยเฉพาะเพื่อความรวดเร็ว ในขณะที่ภาษาโปรแกรมอื่นๆ จะถูกส่งเข้าไป Transform โหนด AST ตามกฎของแต่ละภาษา

Zero-copy String Slicing

ในมุมของการรีด Performance นี่คือจุดที่ Rust ได้โชว์ศักยภาพอย่างแท้จริง การทำงานกับ String และ AST ขนาดใหญ่มักตามมาด้วยคอขวดของการจองหน่วยความจำ (Allocation) แต่ Skim ถูกออกแบบมาให้ทำงานแบบ Zero-copy string slicing โดยมันจะทำการอ้างอิง Source bytes จากต้นฉบับโดยตรงโดยไม่ต้อง allocate หน่วยความจำใหม่เลย ผลจากการจัดการ Memory ระดับลึกนี้ ทำให้มันสามารถ Parse ไฟล์ขนาด 3,000 บรรทัดได้ในเวลาเพียง 14.6 มิลลิวินาที เท่านั้น

การประมวลผลแบบขนานด้วย Rayon

นอกจากการประมวลผลไฟล์เดี่ยวที่รวดเร็วแล้ว การสเกลระดับโปรเจกต์ที่มีไฟล์จำนวนมากก็ทำได้อย่างไร้รอยต่อ ผู้เขียนได้นำ rayon เข้ามาช่วยจัดการ Parallel processing ดึงพลังของ Multi-core ออกมาใช้ทำ Data-parallelism ระหว่างไฟล์ต่างๆ ได้อย่างปลอดภัย (Fearless Concurrency) ยิ่งไปกว่านั้น ยังมีการทำ Caching layer ที่ใช้การตรวจสอบเวลาแก้ไขไฟล์ (mtime invalidation) เข้ามาช่วย ทำให้การอ่านไฟล์เดิมซ้ำในครั้งถัดๆ ไป (Repeated reads) ทำความเร็วได้พุ่งทะยานขึ้นอีกถึง 40-50 เท่า

บทสรุปของ Skim นวัตกรรม Tooling แห่งยุค AI

โปรเจกต์นี้นับเป็น Use Case ที่ตอบโจทย์ยอดเยี่ยมในยุค AI และเป็นตัวอย่างในการใช้ Rust พัฒนา Tooling ที่ต้องการความเร็วสูง การจัดการ I/O แบบสตรีมมิ่ง และการจัดการ Memory ที่แม่นยำ ตัวโปรเจกต์เป็น Open source (MIT) รองรับถึง 9 ภาษา (รวมถึง Rust ด้วย) ใครที่สนใจว่าเขาเขียนโค้ดจัดการ AST ร่วมกับ Zero-copy อย่างไรให้เนียนขนาดนี้ สามารถเข้าไปแกะโค้ดศึกษาหรือโหลดมาลองใช้กันได้ที่ GitHub dean0x/skim ครับ

Credit & Reference:

  1. skim GitHub repo
  2. How I strip 90% of code before feeding it to my coding agent

เมื่อความน่าจะเป็นของ AI ปะทะกับความเข้มงวดของ Rust บทเรียนจากการ Modernize ระบบ COBOL ด้วย Rust

📅 วันที่เผยแพร่: 2026-02-25

หากจะนำ COBOL ซึ่งเป็นภาษาที่ขับเคลื่อนโลกการเงินมานานกว่า 60 ปี มาแปลงเป็นภาษา Modern อย่าง Rust ด้วยพลังของ AI (Claude Opus) นั้น หลายคนอาจมองว่าความท้าทายอยู่ที่ความฉลาดของ Model หรือความแม่นยำในการแปลภาษา แต่จากกรณีศึกษาของคุณ Venkateshwar Rao Nagala ที่ได้ลงมือสร้างระบบนี้ขึ้นมา สิ่งที่ปรากฏชัดเจนยิ่งกว่าคือ ความโกลาหลของ AI ที่ต้องการระเบียบวินัยขั้นสูงสุดในการกำกับดูแล และนั่นคือจุดที่ Rust ก้าวเข้ามามีบทบาท ในฐานะโครงสร้างพื้นฐาน (Infrastructure) เพียงหนึ่งเดียวที่สามารถรับมือกับความไม่แน่นอนนี้ได้

กรงขังที่ปลอดภัยสำหรับ AI Agents

โปรเจกต์นี้ถูกออกแบบบนสถาปัตยกรรม Model Context Protocol (MCP) โดยผู้เขียนได้แยกการทำงานออกเป็น 4 Microservices ที่เขียนด้วย Rust (Actix-web) ทั้งหมด หน้าที่ของมันไม่ใช่แค่การรับส่งข้อมูล แต่มันคือการสร้างกรงขังที่ปลอดภัยให้กับ AI Agents ในขณะที่ Python อาจเป็นภาษาแม่ของ AI แต่มันกลับยอมประนีประนอมมากเกินไปสำหรับงาน Infrastructure ที่ต้องจัดการกับ Critical Banking Logic

ผู้เขียนจึงเลือก Rust เพราะระบบนี้ต้องการ Type System ที่เข้มงวดและ Memory Safety ที่ปราศจากการรั่วไหล เพื่อให้มั่นใจว่าเมื่อ AI Agents ตัดสินใจเรียกใช้ Tools หลายตัวพร้อมกัน (Concurrency) ระบบจะยังคงสถานะที่ถูกต้อง (Correctness) และไม่มีทางเกิด Race Condition ที่คาดเดาไม่ได้

Metaprogramming และ Dynamic Dependency

ความลึกซึ้งของ Rust ในโปรเจกต์นี้แสดงออกมาอย่างชัดเจนในส่วนของ Rust MCP Server ซึ่งทำหน้าที่รับ Code ที่ AI เจนเนอเรทออกมาไปคอมไพล์ ความท้าทายที่ซ่อนอยู่คือ AI มักจะจินตนาการ Dependencies ขึ้นมาเองตามบริบทของโค้ด เช่น การเรียกใช้ rust_decimal หรือ num-format โดยที่เราไม่สามารถ Hard-code Cargo.toml ไว้ล่วงหน้าได้

ปัญหานี้บังคับให้ผู้เขียนต้องใช้ Logic ในระดับ Metaprogramming เพื่อ Parse source code ที่ได้รับมา และทำการ Dynamic Dependency Injection เข้าไปในไฟล์ Config ก่อนสั่ง Build กระบวนการนี้หากทำในภาษาอื่นอาจเต็มไปด้วยความเสี่ยง แต่ Rust ช่วยให้การจัดการ String Manipulation และ File I/O เป็นไปอย่างรัดกุมและรวดเร็ว จนสามารถทำ Automated Compilation Pipeline ได้ในระดับ Sub-millisecond

ครูผู้เข้มงวดชื่อ Rust Compiler

ในระหว่างการพัฒนา ความเข้มงวดของ Rust Compiler กลายเป็นทั้งกำแพงและครูผู้สอน โดยเฉพาะเมื่อต้องจัดการกับ Shared State ระหว่าง Async Threads ใน Actix-web ผู้เขียนเล่าถึงปัญหาคลาสสิกอย่าง RwLock<Option<String>> doesn't implement Clone ซึ่งไม่ใช่แค่ Error ที่น่ารำคาญ แต่มันคือการเตือนสติว่าเรากำลังพยายามเข้าถึงข้อมูลในลักษณะที่ไม่ปลอดภัย (Thread Safety)

ในขณะที่ภาษาอื่นอาจปล่อยให้โค้ดชุดนี้รันผ่านไปและไประเบิดทีหลังเมื่อมีโหลดสูงๆ Rust บังคับให้หยุดและออกแบบ Data Ownership ใหม่ตั้งแต่ต้น ผลลัพธ์คือเมื่อโค้ดผ่านการ Compile ทีมพัฒนาแทบจะมั่นใจได้ทันทีว่า Runtime Error จะเป็นศูนย์ ซึ่งเป็นคุณสมบัติที่ประเมินค่าไม่ได้สำหรับระบบ Enterprise

Zero-Trust Layer ด้วย AgentGateway

แต่ส่วนที่สำคัญที่สุดของ Case Study นี้คือความปลอดภัยในยุคของ AI Agents เมื่อเราอนุญาตให้ “Purple Agent” (AI Modernizer) เข้าถึง S3 เพื่ออ่าน Source Code คำถามที่น่ากลัวคือ “จะเกิดอะไรขึ้นถ้า Agent ถูก Compromise หรือเกิด Hallucination?” ผู้เขียนจึงสร้าง AgentGateway ขึ้นมาด้วย Rust เพื่อทำหน้าที่เป็น Zero-Trust Layer ดักทุก Request

ระบบนี้ใช้ JWT Authentication และ Role-Based Access Control (RBAC) ที่ทำงานได้อย่างรวดเร็วด้วย Actix-web ที่รองรับ 8 Worker Threads การใช้ Pattern Matching (match) ของ Rust ในการจัดการ Result<HttpResponse, Error> ทำให้มั่นใจได้ว่าทุกความเป็นไปได้ของการเรียกใช้งาน ไม่ว่าจะสำเร็จหรือล้มเหลว จะถูกจัดการอย่างหมดจด ไม่มีช่องโหว่ให้หลุดรอดไปได้

บทสรุป: ทางรอดเดียวของระบบการเงิน

ท้ายที่สุด การทดลองของคุณ Venkat ไม่ได้พิสูจน์แค่ว่า Rust สามารถทดแทน COBOL ได้ แต่มันแสดงให้เห็นปรัชญาที่ลึกซึ้งกว่านั้น ว่าในโลกที่ AI เต็มไปด้วยความน่าจะเป็น เราต้องการโครงสร้างพื้นฐานที่มีความเป็นเหตุเป็นผลอย่างสมบูรณ์มาคานอำนาจ

Rust ไม่ได้ถูกเลือกเพราะมัน “เร็ว” แต่ถูกเลือกเพราะมัน “ถูกต้อง” และเมื่อเดิมพันคือระบบการเงินของโลกที่ทำงานมากว่า 60 ปี การยอมแลกความสะดวกสบายในการเขียนโค้ดกับความถูกต้องแม่นยำของ Rust จึงไม่ใช่ทางเลือก แต่อาจเป็นทางรอดเดียวที่สมเหตุสมผล

Credit & Reference:

  1. Mainframe-Modernization GitHub repo
  2. Mainframe Modernization COBOL to Rust with AgentGateway Solo io Hackathon 2026

การสร้าง Media Converter ด้วย Rust

📅 วันที่เผยแพร่: 2026-02-06

มี Case Study ที่น่าสนใจเกี่ยวกับการ Rewrite Desktop App จาก Electron มาเป็น Tauri (Rust Backend + Vue Frontend) ซึ่งเป็นตัวอย่างที่ชัดเจนมากว่าทำไม Rust ถึงเป็นภาษาที่ใช่สำหรับการทำ System Utility ที่ต้องการประสิทธิภาพสูง และมี Memory Safety

โปรเจกต์นี้ชื่อว่า “Honeymelon” เป็น Media Converter สำหรับ macOS (Apple Silicon) โดยเฉพาะ ซึ่งผู้พัฒนา (Jerome Thayananthajothy) ได้แชร์บทเรียนสำคัญในการทิ้ง Node.js runtime อันเทอะทะ มาสู่ความเร็วระดับ Native ของ Rust

The Cost of Runtime ทำไมต้องหนีจาก Electron?

ปัญหาคลาสสิกของ Electron คือ Resource Overhead ครับ ผู้พัฒนาพบว่าเวอร์ชันแรกกินแรมมหาศาล (Unreasonable memory consumption) และ Binary มีขนาดใหญ่ (Bloated binary) การเปิด App ขึ้นมาเพื่อแปลงไฟล์ง่ายๆ แต่ต้องรัน Chromium ทั้งตัวเป็นเรื่องที่ Overkill เกินไป

เมื่อย้ายมาใช้ Tauri 2 (Rust Backend) ผลลัพธ์คือ:

  • Startup Time แทบจะ Instant (Rust init FFmpeg capability detection แบบ Background thread ขณะที่ UI render)
  • Memory Usage ลดลงเหลือระดับ Native Utility ไม่ใช่ Web Browser
  • App Size DMG มีขนาดเล็กลงอย่างมหาศาล

Rust Async Runtime vs Node.js Event Loop

จุดที่น่าสนใจที่สุดคือการจัดการ Concurrency ครับ ใน Electron การจัดการ Child Process จำนวนมากผ่าน Node.js Event Loop มักจะมี Overhead ในการ Marshalling ข้อมูลผ่าน Single Thread แต่ในฝั่ง Rust Backend ของ Honeymelon ใช้ประโยชน์จาก Rust’s Async Runtime ร่วมกับ Tauri’s IPC layer ได้อย่างเต็มประสิทธิภาพ

สามารถ handle Concurrent FFmpeg processes ได้โดยไม่มี Overhead เหมือน Node.js และ Resource Management มีการ Implement Logic ที่เรียกว่า “Exclusive mode” สำหรับ Codec ที่กินทรัพยากรสูง (เช่น AV1 หรือ ProRes) ระบบจะ Lock ไม่ให้จ็อบหนักๆ รันซ้อนกันเพื่อป้องกัน Resource Contention ในขณะที่จ็อบเบาๆ สามารถรันขนานกันได้

สิ่งที่ Rust มอบให้

การเลือก Rust ไม่ใช่แค่เรื่องความเร็ว แต่คือ Reliability เพราะ:

  • No Null Pointer Panics: บอกลา undefined is not a function หรือ Crash กลางอากาศขณะแปลงไฟล์
  • Typed Result Values: การใช้ Result<T, E> ทำให้ Error Propagation ถูกจัดการอย่างถูกต้องและครอบคลุมทุกเคส
  • No GC Pauses: เรื่องนี้สำคัญมากสำหรับงาน Real-time progress tracking เพราะ Rust ไม่มี Garbage Collector มาคอย interrupt การทำงาน ทำให้ Progress events ที่ส่งกลับไปหน้าบ้านมีความลื่นไหลและแม่นยำ

Architecture Design Probe, Plan, Execute

สถาปัตยกรรมของ Honeymelon แบ่งเป็น 3 Stage ที่น่าสนใจ โดยมีการแบ่งหน้าที่ระหว่าง Frontend (TS) และ Backend (Rust) อย่างชัดเจน:

  • Stage 1 - Probe (Rust): Backend สั่ง ffprobe เพื่อดึง Metadata (Codec, Resolution, Color Primaries ฯลฯ)
  • Stage 2 - Plan (TypeScript): Logic การตัดสินใจว่าจะ “Remux” (Copy stream) หรือ “Transcode” ย้ายมาทำที่ Frontend ทั้งหมด เพื่อลด Round-trip ไปที่ Rust backend ทำให้ User เห็น Plan ทันที (Zero Latency UX)
  • Stage 3 - Execute (Rust): พระเอกของงาน Rust จะ spawn ffmpeg เป็น Child process และ Dedicated Thread มีการแยก Thread ออกมาเพื่อ parse stderr output ของ FFmpeg แบบ Real-time เพื่อคำนวณ % progress, fps, speed จากนั้น Atomic Writes เพื่อความปลอดภัยของข้อมูล Output file จะถูกเขียนลง Temporary path ก่อน และใช้ Atomic Rename เมื่อ process เสร็จสมบูรณ์ ป้องกันไฟล์เสียหากโปรแกรม Crash หรือถูก Cancel กลางคัน

การจัดการเรื่อง License

หากใครที่เคยทำงานกับ FFmpeg จะรู้ว่าเรื่อง License (LGPL/GPL) นั้นปวดหัว การ Link library (libavcodec) เข้ากับ Rust code ตรงๆ อาจทำให้ Binary ของเราติดเงื่อนไข LGPL ซึ่ง Honeymelon แก้ไขด้วย Process Separation ไม่ใช้การ Dynamic Linking หรือ Library Calls ใช้ Rust รัน FFmpeg เป็น Separate Process สื่อสารผ่าน Command-line args, Standard Streams และ File System เท่านั้น วิธีนี้ทำให้ Code หลักของ Honeymelon สะอาด (Clean) และสามารถ Release ภายใต้ GPL v3 ได้โดยไม่ขัดแย้งกับ License ของ Libraries

บทสรุป

Honeymelon พิสูจน์ให้เห็นว่า “The tools you choose determine the experience” การใช้ Rust คู่กับ Tauri ไม่ใช่แค่ Trend แต่มันคือการปลดล็อกข้อจำกัดทาง Performance ที่ Web Stack ทั่วไปทำไม่ได้ โดยเฉพาะงานที่ต้องยุ่งกับ System Process หนักๆ อย่าง Media Conversion

ใครสนใจลองไปแกะ Source Code ดูครับ เขียนด้วย Rust + Vue 3 ออกแบบมาสำหรับ macOS Apple Silicon โดยเฉพาะ เป็นตัวอย่างที่ดีมากสำหรับการจัดการ Command Execution และ Async ใน Rust ครับ

Credit & Reference:

  1. “Introducing Honeymelon: A Case Study in Building a Better Media Converter” by Jerome Thayananthajothy
  2. Honeymelon GitHub repo
  3. Honeymelon Website

Deep Dive

ภาพลวงตาของ Inline Assembly และศิลปะการ “แต่งเรื่อง” หลอกคอมไพเลอร์ใน Rust

📅 วันที่เผยแพร่: 2026-03-18

เรามักจะมีความเชื่อลึกๆ ว่า เมื่อไหร่ก็ตามที่เราก้าวเข้าสู่เขตแดนของ unsafe และเรียกใช้ Inline Assembly (asm!) หรือ FFI เรากำลังหลุดพ้นจากพันธนาการอันเข้มงวดของ Rust และสามารถสั่งให้ CPU ทำอะไรก็ได้ตามใจชอบ แต่นั่นคือภาพลวงตา เพราะในความเป็นจริง การใช้ Assembly แบบไม่สนกฎเกณฑ์ ไม่ได้แปลว่าคุณกำลังแฮ็กระบบได้อย่างอิสระ แต่มันแปลว่าคุณกำลังเชิญชวน Undefined Behavior (UB) เข้ามาทำลายโค้ดของคุณโดยไม่รู้ตัว

เมื่อ Assembly เมินเฉยกฎ

ลองนึกภาพตามง่ายๆ สมมติเรามีฟังก์ชันหนึ่งที่รับพารามิเตอร์เป็น Shared Reference (&i32) ในทางทฤษฎีของภาษา Rust (หรือที่เรียกว่า Abstract Machine) Reference ตัวนี้มาพร้อมกับสัญญาที่ว่า “จะไม่มีใครหน้าไหนในโลกนี้สามารถเปลี่ยนแปลงค่าของมันได้” ตลอดช่วงอายุการใช้งาน

แต่ถ้าเราหัวหมอ แอบเขียน Inline Assembly ลงไปในฟังก์ชันนั้นเพื่อสั่งแก้ค่าในตำแหน่งหน่วยความจำนั้นดื้อๆ สิ่งที่เกิดขึ้นคือคอมไพเลอร์อย่าง LLVM จะไม่สนใจ Assembly ของคุณเลยในแง่ของการวิเคราะห์โครงสร้าง มันจะมองแค่ว่าในเมื่อตัวแปรนี้เป็น Shared Reference เงื่อนไขที่ตรวจสอบค่าตัวแปรนี้ย่อมเป็นจริงเสมอ มันจึงทำการ Optimize โค้ดส่วนที่ตรวจสอบค่า (เช่น assert!) ทิ้งไปกลางอากาศ ผลลัพธ์คือโค้ดพังทันทีเมื่อเปิดโหมด Optimize นี่คือข้อพิสูจน์ที่ชัดเจนว่า Assembly ไม่สามารถเมินเฉยกฎของ Rust ได้

ศิลปะของการ “เล่าเรื่อง”

แล้วเราจะเขียน Inline Assembly ให้ถูกต้องและปลอดภัยจากการถูกคอมไพเลอร์ทำลายได้อย่างไร คำตอบจาก Ralf Jung (หนึ่งในแกนนำทีม Rust Unsafe Code Guidelines) คือแนวคิดที่ลึกซึ้งและงดงามมาก นั่นคือศิลปะของการ “เล่าเรื่อง” หรือ Storytelling

แนวคิดนี้บอกไว้ว่า ทุกครั้งที่เราเขียนบล็อก Assembly เราต้องสามารถจินตนาการถึง “โค้ด Rust ธรรมดา” ที่อธิบายพฤติกรรมของ Assembly ก้อนนั้นได้สอดคล้องกับสถานะของ Abstract Machine คอมไพเลอร์ไม่ได้สนว่า CPU รันคำสั่งอะไร แต่มันสนว่า “ถ้ามองจากมุมของภาษา Rust โค้ดก้อนนี้กำลังทำอะไรกับหน่วยความจำและตัวแปรบ้าง” Assembly ของเราจะต้องทำงานอยู่ภายใต้กรอบหรือ “เรื่องเล่า” ที่เราแต่งขึ้นมานี้เสมอ

อธิบายการทำงานระดับฮาร์ดแวร์

ความน่าสนใจคือ เมื่อเรานำแนวคิดเรื่องการเล่าเรื่องนี้ไปจับกับงานระดับฮาร์ดแวร์โหดๆ มันช่วยอธิบายการทำงานที่ซับซ้อนได้อย่างเหลือเชื่อ:

  • การจัดการ Page Table: ลองจินตนาการถึงการเขียน OS ที่ต้องจัดการกับ Page Table ซึ่งเป็นสิ่งที่ภาษา Rust ไม่รู้จักเลย แล้วเราจะอธิบายการแก้ไข Page Table ให้คอมไพเลอร์ฟังได้อย่างไร เรื่องเล่าที่ถูกต้องในกรณีนี้คือ การจัดการ Page Table ก็เปรียบเสมือนการเรียกใช้ฟังก์ชันจองหน่วยความจำอย่าง alloc, dealloc หรือ realloc แบบแปลกๆ นั่นเอง เมื่อเราแมปหน่วยความจำใหม่ มันคือการสร้างสิทธิการเข้าถึงขึ้นมาใหม่ และตัวบล็อก Assembly จะทำหน้าที่เป็นเหมือนกำแพงที่คอยขวางไม่ให้คอมไพเลอร์สลับลำดับการทำงานของหน่วยความจำข้ามจังหวะที่เรากำลังจัดการกับ Page Table
  • Non-temporal stores: หรืออีกกรณีที่คลาสสิกมากคือการใช้คำสั่งระดับฮาร์ดแวร์อย่าง Non-temporal stores (เช่น _mm_stream_ps ใน x86) ซึ่งเป็นคำสั่งเขียนข้อมูลทะลุแคชและไม่สนใจลำดับการเขียนข้อมูลปกติ (Total store order) ของ CPU การใช้คำสั่งนี้ลอยๆ จะทำลาย Memory Model ของโปรแกรมจนเกิด Data Race ได้เลย คำถามคือเราจะแต่งเรื่องอธิบายฮาร์ดแวร์ที่ดื้อรั้นแบบนี้อย่างไร คำตอบคือ เราต้องอธิบายให้คอมไพเลอร์ฟังว่า “คำสั่งนี้เปรียบเสมือนการแตกเธรด (Spawn thread) ใหม่ขึ้นมาเพื่อแอบเขียนข้อมูลอยู่เบื้องหลัง” ดังนั้น ถ้าเราอยากให้ข้อมูลซิงก์กันอย่างถูกต้อง เราก็จำเป็นต้องเรียกคำสั่ง _mm_sfence ตามหลัง ซึ่งในมุมของเรื่องเล่า มันก็คือการสั่ง “Join thread” เพื่อรอให้การเขียนข้อมูลเบื้องหลังเสร็จสิ้นนั่นเอง นี่คือการเอาทฤษฎีฝั่งซอฟต์แวร์มาอธิบายข้อจำกัดทางฮาร์ดแวร์ได้อย่างสมบูรณ์แบบ
  • ตัวแปรสถานะระดับโกลบอล (Global State): แม้แต่การจัดการกับตัวแปรสถานะระดับโกลบอลอย่าง Floating-point Control Register ก็ต้องใช้เรื่องเล่าที่ถูกต้อง หากเราเขียน Assembly เพื่อเปลี่ยนโหมดการปัดเศษ (Rounding mode) ของ CPU แล้วปล่อยทิ้งไว้ โค้ดเราจะเป็น UB ทันที เพราะคอมไพเลอร์ทึกทักไปแล้วว่าโหมดนี้จะเป็นค่าเริ่มต้นเสมอเพื่อผลประโยชน์ในการ Optimize เรื่องเล่าที่ถูกต้องจึงต้องเป็นการรวมเอาการเปลี่ยนโหมด, การคำนวณ, และการเปลี่ยนโหมดกลับ มาไว้ใน Assembly บล็อกเดียวกันทั้งหมด เพื่อหลอกคอมไพเลอร์ว่า “นี่คือการเรียกใช้ไลบรารีคำนวณคณิตศาสตร์ธรรมดาที่ไม่ได้กระทบกับสถานะโกลบอลใดๆ”

บทสรุป

เรื่องนี้ทำให้เราเห็นถึงปรัชญาการออกแบบที่ทรงพลังของ Rust Inline Assembly และ FFI ไม่ใช่หลุมดำที่เราจะโยนโค้ดอะไรลงไปก็ได้ แต่เราต้องมีความรับผิดชอบในการเชื่อมโยงพฤติกรรมของฮาร์ดแวร์เข้ากับกฎจักรวาลของภาษา Rust ตราบใดที่เราไม่สามารถจินตนาการสร้างโค้ด Rust ธรรมดามาอธิบายสิ่งที่ Assembly ทำได้ ให้พึงระลึกไว้เสมอว่าโค้ดนั้นเสี่ยงต่อการถูกคอมไพเลอร์แปลความหมายผิดและนำไปสู่บั๊กที่ตามหาต้นตอได้ยากที่สุดครับ

Credit & Reference:

  1. “How to use storytelling to fit inline assembly into Rust”

10 ปีแห่งการรอคอย เจาะลึกสถาปัตยกรรม Allocator ของ Rust และก้าวต่อไปในปี 2026

📅 วันที่เผยแพร่: 2026-03-13

สำหรับนักพัฒนา Rust ในสาย System Programming หรือผู้ที่ต้องรีดประสิทธิภาพระบบในระดับลึก การรอคอย “Custom Allocators” ให้ใช้งานได้จริงบน Stable channel ถือเป็นมหากาพย์ที่ยาวนานมาก หากนับจากวันที่ RFC นี้ถูกเสนอขึ้นมาก็เกือบจะครบหนึ่งทศวรรษแล้ว แม้ผลสำรวจล่าสุดจะชี้ว่ามีผู้ใช้งานจำนวนมากต้องการฟีเจอร์นี้เพื่อปลดล็อกข้อจำกัดของระบบ แต่ทำไมแค่การสร้าง Trait สำหรับจองและคืนพื้นที่หน่วยความจำถึงกลายเป็นโจทย์สถาปัตยกรรมที่ Core Team ต้องถกเถียงกันมายาวนานขนาดนี้

ปรัชญา Zero-cost Abstraction และปัญหา State ของ Allocator

จุดเริ่มต้นของความซับซ้อนนี้มาจากความพยายามที่จะรักษาปรัชญา “Zero-cost Abstraction” ของ Rust ไว้ ในปัจจุบัน Allocator Trait บน Nightly ถูกออกแบบมาอย่างเรียบง่าย มีเพียงฟังก์ชันจอง (allocate) และฟังก์ชันคืน (deallocate) เมื่อเราใช้งานโครงสร้างข้อมูลอย่าง Vec ควบคู่กับ Global Allocator ซึ่งไม่มีการเก็บ State ใดๆ ตัวคอมไพล์เลอร์จะฉลาดพอที่จะยุบรวมโค้ด (Inline) ทำให้ขนาดของ Vec ยังคงมีแค่พอยน์เตอร์ ความยาว และความจุเท่าเดิมเป๊ะ

แต่ปัญหาจะเริ่มปรากฏเมื่อเราจำเป็นต้องเขียน Allocator ที่มีการเก็บ State ของตัวเอง ซึ่งจะส่งผลให้ขนาดของ Container อย่าง Vec หรือ Box ต้องบวมขึ้นเพื่อเก็บตัว Allocator นี้เอาไว้ใช้ในจังหวะที่ต้องคืนหน่วยความจำ

อุปสรรคของ Zero-Sized Allocations

อุปสรรคแรกที่ทำให้ฟีเจอร์นี้ยังไปไม่ถึงฝั่งฝันคือเรื่องการจองพื้นที่ขนาดศูนย์ไบต์ (Zero-Sized Allocations) ปัจจุบันตัวกำหนดโครงสร้างหน่วยความจำ หรือ Layout อนุญาตให้เราส่งค่าขนาดเป็นศูนย์ได้ ซึ่งในทางปฏิบัติไม่ได้มีการจองพื้นที่จริง และ Allocator มักจะคืนค่าพอยน์เตอร์ตัวเดิมกลับมาซ้ำๆ พฤติกรรมนี้เองที่สุ่มเสี่ยงต่อการทำลายตรรกะความเท่ากันของพอยน์เตอร์ และอาจเป็นช่องโหว่ที่นำไปสู่ Undefined Behavior ได้ในบางกรณี ทางออกที่วงในกำลังถกเถียงกันคือการเปลี่ยนไปใช้ NonZeroLayout เพื่อบังคับให้ทุกการจองต้องมีขนาดเสมอ ตัดปัญหาความคลุมเครือนี้ทิ้งไปตั้งแต่ระดับ Type System

ความต้องการ Context ในบริบทของ Kernel

แต่ความท้าทายไม่ได้หมดแค่นั้น หากเรามองไปที่กลุ่มผู้ใช้งานระดับฮาร์ดคอร์อย่างทีม Rust for Linux พวกเขาไม่สามารถรอให้ฟีเจอร์นี้เสร็จสมบูรณ์ได้ และต้องแยกไปสร้าง Allocator Trait ของตัวเอง เหตุผลสำคัญคือในระดับเคอร์เนล การจองหน่วยความจำไม่ได้อิงแค่ “ขนาด” แต่ต้องการ “บริบท” (Context) ด้วย เช่น ต้องระบุ Flag การทำงาน หรือเจาะจง NumaNode สิ่งนี้สะท้อนให้เห็นว่า Trait พื้นฐานของ Rust อาจจะยังยืดหยุ่นไม่พอ และอาจมีความจำเป็นต้องเพิ่ม Associated Type เพื่อเปิดทางให้ผู้เรียกสามารถส่งผ่าน Context เข้าไปได้

Bump Allocator และปัญหาการคืนหน่วยความจำ

นอกจากนี้ เมื่อเราพูดถึงกระบวนทัศน์การจัดการหน่วยความจำแบบพิเศษอย่าง “Bump Allocator” ซึ่งมีพฤติกรรมกวาดล้างคืนพื้นที่ทั้งหมดในรวดเดียว มันแทบไม่มีความจำเป็นต้องใช้ฟังก์ชัน deallocate สำหรับข้อมูลแต่ละชิ้นเลย แต่ด้วยดีไซน์ปัจจุบัน หากเราสร้าง Box จาก Bump Allocator ตัวกล่องก็ยังถูกบังคับให้ต้องจดจำ State ของ Allocator ไว้เพื่อรอจังหวะ Drop ทำให้สูญเสียพื้นที่หน่วยความจำไปอย่างเปล่าประโยชน์

แม้จะมีข้อเสนอให้จับหั่นแบ่ง Trait ออกเป็นส่วน Allocator และ Deallocator แต่ก็ต้องแลกมากับความยุ่งยากมหาศาลในการแปลง Type ข้ามไปมา หรือแย่ที่สุดคืออาจต้องยอมให้เกิด Runtime Panic ซึ่งเป็นสิ่งที่ขัดกับหัวใจของ Rust อย่างรุนแรง เช่นเดียวกับเรื่องของการจัดการ Error ที่ปัจจุบันเป็นเพียง Type ว่างๆ ที่ไม่มีข้อมูลอะไรเลย ทำให้การดึงข้อมูลบริบทกลับมาเพื่อทำ Error Recovery แทบจะเป็นไปไม่ได้ จนเกิดเป็นข้อเสนอที่อยากให้มี Associated Type สำหรับ Error โดยเฉพาะ

บอสใหญ่: Static vs Dynamic Dispatch

แต่สิ่งที่ถือเป็น “บอสใหญ่” ในเชิงสถาปัตยกรรมจริงๆ คือปมเรื่องรอยต่อระหว่าง Static และ Dynamic Dispatch ปัจจุบัน Rust เลือกใช้ Generics สำหรับรับชนิดของ Allocator (เช่น Vec<T, A>) ซึ่งจะทำให้เกิดกระบวนการ Monomorphization หรือการปั๊มโค้ดออกมาชุดใหม่ทุกครั้งที่เราเปลี่ยน Allocator ผลที่ตามมาคือขนาดของไบนารีที่ใหญ่ขึ้น (Code Bloat) และสร้างความเจ็บปวดให้กับฝั่งผู้เรียกใช้งาน เพราะเราไม่สามารถโยน Vec ที่สร้างจาก Allocator คนละตัวเข้าไปในฟังก์ชันเดียวกันได้โดยตรง

เมื่อเราหันไปมองภาษาอื่นอย่าง C++ ที่แก้ปัญหานี้ในมาตรฐาน C++17 ด้วยการใช้ Polymorphic Memory Resources (Type Erasure) หรือภาษา Zig ที่เลือกใช้โครงสร้างแบบ VTable (Dynamic Dispatch) เป็นค่าเริ่มต้น ซึ่งแม้ในทฤษฎีจะดูช้ากว่า แต่ในทางปฏิบัติกลับช่วยลดปัญหา Instruction Cache Misses จนทำงานได้เร็วกว่าในบางสภาวะ สำหรับตัว Rust เอง เราสามารถอาศัยท่า Box<dyn Allocator> เพื่อทำ Dynamic Dispatch ได้เช่นกัน และเราอาจคาดหวังความเก่งกาจของ LLVM ในการช่วยแกะรอยและแปลงกลับเป็น Static Inline ให้ในจังหวะคอมไพล์ ซึ่งจะช่วยให้เราได้ทั้งความยืดหยุ่นและประสิทธิภาพไปพร้อมๆ กัน

ก้าวต่อไปในปี 2026: 3 ทางเลือก

เมื่อมองภาพรวมทั้งหมดในปี 2026 เรากำลังยืนอยู่บนทางแยก 3 สายหลักครับ:

  1. สายแรก คือรอต่อไปจนกว่าจะมีทางเลือกใหม่ที่ดีกว่าแบบก้าวกระโดดโผล่ขึ้นมา
  2. สายที่สอง คือยอมหักดิบประกาศ Stabilize Trait ในสภาพปัจจุบันไปเลย แล้วยอมปล่อยมือจาก Use case เฉพาะทางอย่างงานเคอร์เนล
  3. สายที่สาม คือยอมประนีประนอม ปรับแต่ง Trait อีกเล็กน้อยโดยเพิ่มองค์ประกอบอย่าง Context, การบังคับ Layout แบบไม่เป็นศูนย์ และระบบ Error ที่ดีขึ้น เข้าไปเป็นส่วนหนึ่งของดีไซน์หลักก่อนจะประกาศใช้จริง

Credit & Reference:

  1. The State of Allocators in 2026

Lambda From Scratch: เขียน Custom Runtime เองด้วย Rust แบบไม่ง้อ SDK

📅 วันที่เผยแพร่: 2026-02-28

ปกติเวลาเราเขียน AWS Lambda ด้วย Rust เรามักจะจบที่ crate lambda_runtime หรือใช้ cargo-lambda ซึ่งมันสะดวกมาก แต่เคยสงสัยไหมครับว่า “under the covers” ของ Lambda Runtime จริงๆ แล้วมันคุยกับ AWS Infrastructure อย่างไร

มี Case Study ที่น่าสนใจมากครับ เป็นการเขียน Lambda แบบ “Stripped down” สุดๆ ใช้แค่ crate reqwest และ serde_json เท่านั้น เพื่อ Implement Lambda Runtime API ด้วยตัวเอง โพสต์นี้ผมจะพาไปดู Mechanism การทำงานระดับ Low-level ของ Serverless และเทคนิคการ Build Rust ให้เป็น bootstrap binary ที่ทรงพลังครับ

1. Lambda is just a loop การเข้าใจ Abstraction เป็นเรื่องสำคัญ

จริงๆ แล้ว Lambda ไม่ได้ถูกเรียก (Push) โดยตรงเสมอไป แต่มันทำงานผ่าน Polling Model ภายใน Execution Environment ซึ่ง Environment ของ AWS จะ Inject Environment Variable ตัวสำคัญมาให้คือ AWS_LAMBDA_RUNTIME_API หน้าที่ของ Binary ของเรา (ในฐานะ Custom Runtime) มีแค่:

  • Init Phase: จอง Memory, Connect DB (ทำนอก loop main())
  • Processing Loop: GET request ไปยัง http://{runtime_api}/.../invocation/next (ขั้นตอนนี้ Runtime จะ block จนกว่าจะมี Event เข้ามา หรือโดน Freeze) Process logic และ POST response กลับไปที่ endpoint เดิม

ความสวยงามของ Rust คือเราสามารถควบคุม Flow นี้ได้ 100% โดยลด abstraction layer ของ language runtime ลงจนเหลือ interaction กับ Lambda Runtime API โดยตรง แทนที่จะใช้ Macro #[lambda_runtime::main] เราเขียน fn main() ธรรมดาเลย

Note: การจัดการ Error handling และ Retries ในจังหวะ Polling เป็นสิ่งที่ต้อง Handle เองหากทำ Custom Runtime (ตามตัวอย่าง (Ref) มีการทำ Retry logic 3 ครั้งหาก Fetch ไม่สำเร็จ)

2. จุดที่ Rust กินขาดคือเรื่อง Static Linking และ Binary Size

เพื่อให้รันบน Amazon Linux (AL2/AL2023) ได้โดยไม่ต้องปวดหัวกับ glibc version mismatch เทคนิคมาตรฐานคือการ compile target x86_64-unknown-linux-musl

# Build release for MUSL
cargo build --release --target x86_64-unknown-linux-musl

# Rename to 'bootstrap'
# AWS Custom Runtime มองหาไฟล์ executable ชื่อนี้เท่านั้น
cp target/x86_64-unknown-linux-musl/release/lambda_impl bootstrap

# Strip Symbols (Optional but recommended)
strip bootstrap

ผลลัพธ์ที่ได้คือ Binary เดี่ยวๆ (Single Binary) ที่มีขนาดเล็กมาก (Minimal footprint) ไม่มี Dependencies ภายนอก และช่วยลด overhead ของ runtime layer และมีศักยภาพในการทำ cold start ให้เร็วขึ้น

3. บทสรุป

การเขียนแบบนี้อาจจะไม่เหมาะกับ Production ทั่วไป (ใช้ crate มาตรฐานเถอะครับ 😅 ปลอดภัยกว่าเรื่อง Edge cases) แต่ในเชิงวิศวกรรม มันทำให้เห็นว่า:

  • Memory Safety: รัสต์ (Rust) การันตี memory safety แม้เราจะเขียน low-level interaction เอง
  • Performance: เราตัด Middleware ที่ไม่จำเป็นออกได้ทั้งหมด
  • Cross-Compilation: Rust toolchain จัดการเรื่อง Cross-compile ไป MUSL ได้เนียนตาที่สุดภาษาหนึ่งเลยครับ

ใครที่กำลังมองหา High-performance Serverless หรือต้องการ Optimize Cost/Latency สูงสุด Rust เป็นตัวเลือกที่ดีมากสำหรับ use case ที่ต้องการควบคุม latency และ footprint สูงสุด

Credit & Reference:

  1. Lambda From Scratch

เจาะลึกสถาปัตยกรรม “Leptos” กับแนวคิด Fine-Grained Reactivity

📅 วันที่เผยแพร่: 2026-02-10

การพัฒนา Rust Web Development เรามักคุ้นเคยกับ Framework ที่พยายามยกโมเดลของ React มาใส่ใน Rust (เช่น Yew) ซึ่งแม้จะปลอดภัยและเขียนสนุก แต่ลึกๆ แล้วเรายังต้องจ่าย “ภาษี” ให้กับระบบ Virtual DOM (VDOM) ไม่ว่าจะเป็นการ Diffing trees หรือการ Re-render component ซ้ำๆ เมื่อ State เปลี่ยน ซึ่งฟังดูแล้วมันขัดแย้งกับปรัชญา Zero-cost abstractions ที่ชาว Rustacean ยึดถือ แต่วันนี้ผมอยากพาไปรู้จัก Leptos (เล็ปโตส) Framework ที่กล้าทิ้ง VDOM และนำศักยภาพของ Rust มาใช้รีดประสิทธิภาพ Web Assembly (WASM) จนถึงขีดสุด

การปลดปล่อยจาก VDOM สู่ Fine-Grained Reactivity

เรื่องราวของ Leptos นั้น เริ่มต้นที่การตั้งคำถามกับ Paradigm เดิมๆ แทนที่จะมองว่า UI คือฟังก์ชันที่ต้องรันซ้ำๆ เพื่อสร้าง Tree ใหม่ (แบบ Yew หรือ Dioxus) Leptos เลือกเดินเส้นทางของ Fine-Grained Reactivity ซึ่งเปลี่ยนกระบวนการคิดของเราไปโดยสิ้นเชิง ใน Leptos นั้น Component Function (#[component]) จะถูกรันเพียงแค่ครั้งเดียว (Run once) ในตอน Initialization เพื่อสร้าง DOM Nodes จริงๆ ขึ้นมา จากนั้นระบบจะสร้าง “Reaction Graph” ผูกติดไว้กับจุดต่างๆ ใน DOM โดยตรง

นั่นหมายความว่า เมื่อ Signal มีการเปลี่ยนค่า Runtime ของ Leptos ไม่จำเป็นต้อง Traverse ดูว่า Component ไหนต้อง Render ใหม่ แต่ระบบจะวิ่งตรงไปยัง Text Node หรือ Attribute นั้นๆ แล้วทำการ Update ทันทีด้วยความซับซ้อนระดับ O(1) นี่คือการขจัด Overhead ของ VDOM ทิ้งไปอย่างสมบูรณ์ ทำให้เราได้ Performance ที่ดิบและใกล้เคียงกับการเขียน Vanilla JS DOM manipulation ด้วยมือมากที่สุด แต่ยังคงความ Declarative ผ่าน view! macro ได้อย่างสวยงาม

หมดปัญหา Borrow Checker ด้วย Copy & ’static Signals

อีกหนึ่งความเจ็บปวดของการเขียน UI ใน Rust คือการต่อสู้กับ Borrow Checker เมื่อต้องส่ง State เข้าไปใน Closures หลายๆ ชั้น ซึ่ง Leptos แก้ปัญหานี้ด้วยการออกแบบ Primitives ของ Signals ให้เป็น Copy และ 'static สิ่งนี้ไม่ใช่แค่เรื่องของ Syntax Sugar แต่มันคือการออกแบบ Memory Management ที่ชาญฉลาด ทำให้เราสามารถ move signal (เช่น read_signal, write_signal) เข้าไปใน Event Listeners หรือ Derived Signals ได้นับครั้งไม่ถ้วนโดยไม่ต้องสั่ง .clone() ให้รก code และไม่ต้องปวดหัวกับ Lifetime hell ซึ่งถือเป็น Developer Experience (DX) ที่ก้าวกระโดดจาก Framework ยุคก่อนหน้า

Isomorphic Framework แบบ Full-stack ขนานแท้

แต่ Leptos ไม่ได้หยุดแค่การเป็น Client-side Library ที่เร็วเท่านั้น มันถูกวางสถานะเป็น Full-stack Isomorphic Framework ตั้งแต่ต้นน้ำ ยิ่งเมื่อทำงานร่วมกับ cargo-leptos เราจะเห็นศักยภาพของการทำ Server Functions ที่ทำให้เส้นแบ่งระหว่าง Client และ Server จางลง คุณสามารถเขียนฟังก์ชันดึง Database ในไฟล์เดียวกับ Component แล้วเรียกใช้เหมือนฟังก์ชันปกติ (RPC-like) โดยระบบจะจัดการเรื่อง Serialization/Deserialization ให้เอง

เบื้องหลังมันคือการรองรับมาตรฐาน Web สมัยใหม่อย่างแท้จริง ทั้งการทำ HTML Streaming แบบ Out-of-order และ <Suspense/> ที่ช่วยให้ User เห็น Content ได้ไวที่สุดโดยไม่ต้องรอ Data ทั้งก้อน (Holistic Web Performance)

ปรัชญาและจุดยืนของ Leptos

หากเปรียบเทียบในเชิงปรัชญา ชื่อ “Leptos” (ภาษากรีกแปลว่า บาง, เบา, ละเอียด) สะท้อนตัวตนของ Framework ได้ดีที่สุด ในขณะที่ Yew แบก VDOM และ Dioxus โฟกัสที่ Cross-platform (Desktop) Leptos เลือกที่จะโฟกัสที่ “Web Platform” อย่างเข้มข้นที่สุด โดยใช้ระบบ Reactive ที่ละเอียดอ่อน (Fine-grained) เพื่อตัดส่วนเกินที่ไม่จำเป็นออกไป

สำหรับ Rust Dev ที่กำลังมองหาเครื่องมือที่เคารพทรัพยากรเครื่อง และต้องการเขียน Web App ที่ Scale ได้ด้วย Architecture ที่ถูกต้อง (ไม่ใช่แค่เร็วเพราะเป็น WASM แต่เร็วเพราะ Algorithm การ Update มันถูกออกแบบมาดี) Leptos คือคำตอบที่น่าจะตรงใจที่สุดในเวลานี้ครับ 😊

ใครที่สนใจ แนะนำให้ลองดู cargo-leptos หรืออ่าน Book ใน Official Docs ดูครับ แล้วคุณจะพบว่า Rust บน Web มันไปได้ไกลกว่าที่เราเคยคิดไว้เยอะ ยิ่งล่าสุดพี่สิทธิ์ Sitt Guruvanich แชร์เรื่อง Rust/ui ก็มาเสริมเติมเต็มได้อย่างดีเลยครับ

Credit & Reference:

  1. Leptos GitHub repo
  2. Leptos Book
  3. cargo-leptos GitHub

Rust Blockchain

เมื่อ Rust บุกโลก EVM: เจาะลึก Architecture ของ Arbitrum Stylus ผ่าน Claude Code Skill

📅 วันที่เผยแพร่: 2026-02-06

ในการพัฒนา Web3 มักมีช่องว่างขนาดใหญ่ที่น่าอึดอัดใจอยู่เรื่องหนึ่ง ฝั่งหนึ่งเรามี Tutorial ระดับ “Hello World” ที่สอนแค่ Deploy Counter Contract ง่ายๆ แล้วจบไป แต่อีกฝั่งคือ Production Codebase ขนาดมหึมาที่เต็มไปด้วย Configuration ซับซ้อนซึ่งต้องใช้เวลาหลายเดือนในการตกผลึก

ปัญหาที่ Ben Greenberg (DevRel จาก Arbitrum) ค้นพบคือ เมื่อ Developer พยายามใช้ AI อย่าง Claude เพื่อปิดช่องว่างนี้ AI มักจะให้ Code ที่ “ดูเหมือนจะถูก” แต่กลับใช้ SDK เวอร์ชันเก่า หรือใช้ Pattern ที่พังทันทีเมื่อรันบนระบบใหม่อย่าง Arbitrum Stylus

Claude Code Skill คืออะไร?

ชุดความรู้แบบ Structured Markdown ที่ไม่ได้แค่ Gen code แต่ทำหน้าที่เป็น Engineering Manager ที่คอยวาง Architecture ให้เราตั้งแต่ต้น และที่น่าสนใจที่สุดคือ Rust ถูกยกให้เป็น First-class citizen เคียงคู่กับ Solidity ในฐานะเครื่องมือสำหรับโปรเจกต์ที่ต้องการ Maximum Performance และ Low Gas Cost

Rust บน EVM: Memory Model และ sol_storage

หัวใจสำคัญที่ทำให้ Rust เฉิดฉายบน EVM ผ่าน Arbitrum Stylus ได้นั้น อยู่ที่การจัดการความต่างของ Memory Model ระหว่าง Rust และ EVM

stylus-sdk: สะพานเชื่อม Rust กับ EVM

  • ใช้ stylus-sdk เวอร์ชัน 0.10+ ที่เสถียรต่อ breaking changes
  • Macro sol_storage! ทำหน้าที่เป็น Abstraction Layer ใน Map Rust Structs → Storage Slots ของ EVM (32-byte key-value pairs)
  • ประกาศ struct NftContract พร้อมใช้ Type พิเศษอย่าง mapping(uint256 => address) ภายใน Macro ได้เลย

แทนที่เราจะต้องจัดการเรื่อง Slot Hashing เอง เราได้ Type Safety ตั้งแต่ Compile Time พร้อมกับประสิทธิภาพระดับ Native WASM ซึ่งเป็นสิ่งที่ Solidity แบบดั้งเดิมให้ไม่ได้

Implementation: ความเข้มงวดที่เป็นเอกลักษณ์ของ Rust

เมื่อเจาะลึกลงไปใน Implementation ของ Contract ผ่าน impl block เราจะเห็นความเข้มงวดที่เป็นเอกลักษณ์ของ Rust เข้ามาช่วยกำจัด Bug ระดับ Low-level

Rust Patterns ใน Smart Contract

  • #[entrypoint] — กำหนดจุดรับ Calldata จากภายนอก
  • &mut self — การแก้ไข State ต้องประกาศชัดเจน
  • .get() / .set() — Stylus บังคับให้ใช้ Pattern นี้สำหรับ Storage field อย่าง total_supply หรือ owners
  • U256 / Address type จาก alloy_sol_types — ป้องกัน Overflow/Underflow

ดู Verbose แต่มีเหตุผล

แม้ Pattern .get() / .set() จะดูเหมือน Verbose กว่า Solidity เล็กน้อย แต่มันทำให้ Developer ตระหนักถึง “Cost” ของการทำ SLOAD และ SSTORE ในทุกบรรทัด — ทุก Storage Access มีค่า Gas!

Developer Experience: End-to-End Type Safety

ในมุมของ Developer Experience และ Tooling การออกแบบ System Architecture ผ่าน Claude Skill นี้เลือกใช้ Monorepo Structure ที่ขับเคลื่อนด้วย pnpm workspace แต่หัวใจหลักยังคงเป็น Cargo ecosystem สำหรับส่วนของ Contract

Workflow แบบไร้รอยต่อ

ขั้นตอนคำสั่งผลลัพธ์
เขียน ContractRust + stylus-sdkType-safe Smart Contract
Deploycargo stylus deployส่ง WASM ขึ้น Chain
Generate ABIcargo stylus export-abiABI สำหรับ Frontend
Frontend เรียกใช้wagmi + viemTypeScript catch error ทันที

โปรเจกต์จะถูก Scaffold ขึ้นมาพร้อมกับ nitro-devnode (Local Arbitrum chain ใน Docker) ซึ่งพร้อมรันทันที TypeScript ฝั่ง Frontend จะ Catch error ได้ทันทีถ้าเราเรียกชื่อฟังก์ชันผิดหรือส่ง Type ผิด นี่คือ End-to-End Type Safety ที่เชื่อมโลกของ Smart Contract และ Client Side เข้าด้วยกันอย่างสมบูรณ์

บทสรุป

Rust คือ ‘Real Deal’ ในยุคถัดไปของ Smart Contract

สิ่งที่ Ben Greenberg นำเสนอไม่ใช่แค่ Tool ช่วยเขียนโค้ด แต่เป็นการประกาศว่า Rust พร้อมแล้วที่จะเป็นแกนหลักใน Application Layer ของ Blockchain

Decision Tree ของระบบแนะนำให้เลือก Stylus Rust เมื่อต้องการประสิทธิภาพสูงสุด เป็นเครื่องยืนยันว่าเราเขียน Rust บน Blockchain ไม่ใช่เพราะเราชอบภาษานี้ แต่เพราะมันมอบ Architecture ที่เหนือกว่า ทั้งในแง่ของ:

  • Execution Speed
  • Gas Optimization
  • Memory Safety

หากใครที่เคยลังเลว่าจะเอาความรู้ Rust มาใช้ในโลก EVM อย่างไร นี่คือ Use case ที่พิสูจน์แล้วว่า Rust คือ “Real Deal” ในยุคถัดไปของ Smart Contract Development

Credit & Reference:

  1. How I Built a Claude Code Skill That Scaffolds Complete Arbitrum dApps
  2. arbitrum-dapp-skill Documentation
  3. X post
  4. Build a dApp on Arbitrum with Claude (Video)
  5. arbitrum-dapp-skill GitHub repo

Rust Core

เมื่อ Trait ไม่ใช่แค่เงื่อนไข แต่คือพารามิเตอร์ลับที่ Compiler แอบส่งให้คุณ

📅 วันที่เผยแพร่: 2026-03-23

ในฐานะผู้ใช้ Rust เรามักจะเขียนโค้ดที่ดูเรียบง่าย เช่น my_val.clone() โดยไม่ต้องคิดเยอะว่าข้างหลังเกิดอะไรขึ้น แต่เบื้องหลังความเรียบง่ายนี้มีงานหนักของคอมไพเลอร์ที่เรียกว่า “Trait Solving” คอยจัดการให้ หน้าที่ที่ซับซ้อนที่สุดอย่างหนึ่งของ rustc เลยก็ว่าได้

มุมมอง Dictionary-Passing Style (DPS)

ทีมวิจัย Rust Types ได้นำโมเดลจากทฤษฎีไทป์ (ได้แรงบันดาลใจจาก Haskell) มาพิจารณาว่า Trait อาจถูกมองเป็น struct หนึ่งตัว และการเขียน impl สำหรับไทป์ใดไทป์หนึ่งก็คือการสร้าง “ค่าอินสแตนซ์” ของ struct ตัวนั้น

ในมุมมองนี้ การประกาศว่า u32 สามารถ Clone ได้ อาจถูกคิดเป็นเหมือนการสร้างค่าคงที่ (a const struct) ที่เก็บพอยน์เตอร์ไปยังฟังก์ชันที่จำเป็นสำหรับการทำสำเนาไว้ — ดังนั้นเมื่อเราต้องการเรียก clone() สิ่งที่ถูกส่งมาพร้อมกับค่าจริงอาจเป็นดิกชันนารีลับๆ ที่บรรจุพอยน์เตอร์เหล่านั้น

Trait Elaboration: เงื่อนไขไม่ได้เป็นแค่การตรวจสอบ

เมื่อเรากำหนดขอบเขตแบบ where T: Clone ในมุมมอง DPS นั่นไม่ใช่แค่การเช็คว่าไทป์ตรงตามเงื่อนไขหรือไม่ แต่มันเหมือนเป็นการบังคับให้ผู้เรียกใช้งาน (caller) ต้องส่งอินสแตนซ์ของดิกชันนารี (dictionary instance) เข้ามาด้วย — เป็นพารามิเตอร์ที่คอมไพเลอร์ต้องหาและเติมให้สมบูรณ์

กระบวนการที่คอมไพเลอร์ใช้ในการเติมเต็มพารามิเตอร์ลับเหล่านี้ เราเรียกว่า “Trait Elaboration” — ขั้นตอนนี้คือการจับคู่ trait bound กับอินสแตนซ์ที่เหมาะสม และผูกพอยน์เตอร์ให้กับการเรียกใช้งานจริงเมื่อคอมไพล์

เมื่อ Associated Types ซับซ้อนกว่าแค่พอยน์เตอร์

โมเดล DPS อธิบายได้ดีเมื่อ trait มีเพียงพอยน์เตอร์ของฟังก์ชัน แต่ Associated Types เพิ่มความซับซ้อนอย่างมาก เช่น T: Iterator<Item = u32] ในกรณีนี้ ดิกชันนารีไม่ได้เก็บแค่พอยน์เตอร์ของฟังก์ชัน แต่ยังมีไทป์ฝังตัวอยู่ด้วย

เพื่อให้ Type Checker ยอมรับได้ Compiler มักต้องสร้างหรือสมมติ “บทพิสูจน์ความเท่ากัน” (equality bounds) เสมือนว่ามีพารามิเตอร์ลับอีกชิ้นมายืนยันว่า Item นั้นเท่ากับ u32 จริง ๆ การติดตามและพิสูจน์ความเท่ากันของไทป์เหล่านี้จึงกินทรัพยากรและเพิ่มความซับซ้อนอย่างมีนัยสำคัญ

ปัญหาเมื่อมี Global impls และบทบาทของ Coherence

ในโลกของ DPS ล้วน ๆ การมีการอิมพลีเมนต์แบบครอบจักรวาล (global impl) สำหรับไทป์ T อาจทำให้ฟังก์ชันที่รับพารามิเตอร์ซ้อนทับกันไม่สามารถยืนยันได้ว่าไทป์สองตัวคือสิ่งเดียวกันโดยอัตโนมัติ — เพราะอาจมีผู้ใช้งานส่งดิกชันนารีคนละเล่มเข้ามาได้

สิ่งที่ทำให้ Rust ปัจจุบันหลีกเลี่ยงความกำกวมนี้ได้คือกฎความสอดคล้อง (Coherence) ซึ่งรับประกันว่า สำหรับคู่ (type, trait) หนึ่ง ๆ จะมีการอิมพลีเมนต์ได้เพียงหนึ่งเดียวในทั้งจักรวาลของโค้ด นโยบายนี้ช่วยลดความกำกวม แต่การบูรณาการ Coherence เข้ากับโมเดล DPS อย่างสมเหตุสมผล เป็นงานที่ท้าทายสำหรับทีมคอมไพเลอร์

ทำไมต้องลงลึก — เรื่องของ Soundness

เหตุผลหลักที่ทีมวิจัยต้องไล่ลงรายละเอียดเรื่องนี้คือเรื่องของ “Soundness” — ความถูกต้องและความปลอดภัยของระบบไทป์ในระดับรากฐาน ปัญหาคือ Trait Solver ปัจจุบันยังมีช่องว่างในกรณีที่ซับซ้อนมาก ๆ: การค้นหาบทพิสูจน์ไทป์อาจนำไปสู่การอ้างอิงวนซ้ำ (cyclic reasoning) ซึ่งในที่สุดอาจทำให้โค้ดที่ดูปลอดภัย (safe code) สร้าง Undefined Behavior ในตอนรันไทม์ได้

การจัดกรอบการคิดด้วย DPS ช่วยให้ทีมเห็นภาพชัดเจนขึ้นว่าช่วงไหนของระบบรับประกันความปลอดภัยทางคณิตศาสตร์ และช่วงไหนที่เสี่ยง — ซึ่งสำคัญเพื่อการออกแบบการแก้ปัญหาหรือการตัดสินใจปฏิเสธรูปแบบโค้ดบางอย่างเพื่อความปลอดภัย

โอกาสกับฟีเจอร์ Specialization

หนึ่งในฟีเจอร์ที่ถูกหวังว่าจะปลดล็อกได้จากความเข้าใจเชิง DPS คือ “Specialization” — ความสามารถในการนิยาม impl ที่เฉพาะเจาะจงทับ impl ทั่วไปได้ ปัญหาหลักที่ทำให้ specialization ถูกระงับมานานคือความเสี่ยงต่อ soundness เมื่อผสานกับ Coherence และ Trait Solving

การมีกรอบ DPS ที่ชัดเจนอาจช่วยให้ทีมวางนโยบายที่พิสูจน์ได้ทางทฤษฎีว่าการอนุญาต specialization รูปแบบใดปลอดภัย และรูปแบบใดควรถูกปฏิเสธ

สรุป

โค้ด Rust ที่ดูสะอาดเรียบง่ายซ่อนสถาปัตยกรรมคอมไพเลอร์ที่ซับซ้อนอยู่เบื้องหลังอย่างมาก โมเดล Dictionary-Passing Style เป็นมุมมองหนึ่งที่ช่วยให้ทีมวิจัยและนักพัฒนาคอมไพเลอร์เข้าใจการทำงานของ Trait, Associated Types, และการแก้ปัญหาเรื่อง Coherence ได้ดียิ่งขึ้น — ทั้งนี้เพื่อรักษา Soundness และเปิดทางให้ฟีเจอร์เช่น Specialization สามารถถูกนำมาใช้ได้อย่างปลอดภัยในอนาคต

Credit & Reference:

  1. Rust Types team: “Elaborating Rust Traits to Dictionary-Passing Style” — https://nadrieril.github.io/blog/2026/03/20/dictionary-passing-style.html

เมื่อสถาปัตยกรรมของภาษาไม่อาจลอกเลียนแบบได้ ทำไม Error Handling ของ Rust ถึงเป็น Masterpiece

📅 วันที่เผยแพร่: 2026-03-11

บทความนี้ผมมีเรื่องราวเชิงสถาปัตยกรรมของภาษาที่น่าสนใจมากมาเล่าให้ฟัง เป็นมุมมองจากเดฟสาย Rust (Abid Omar) ที่ต้องย้ายไปจับงาน Front-end ด้วย TypeScript เป็นเวลาเกือบปี ประสบการณ์ของเขาได้สะท้อนให้เห็นถึงแก่นแท้ของการออกแบบภาษา Rust ว่าทำไมระบบอย่าง Result ถึงไม่ใช่แค่รูปแบบการเขียนโค้ด (Design Pattern) แต่มันคือนวัตกรรมระดับคอมไพเลอร์ที่ภาษาอื่นทำตามได้ยากมาก โดยเฉพาะเมื่อต้องเจอกับข้อจำกัดของ TypeScript ที่โค้ดมักจะกลายพันธุ์เป็นชนิดข้อมูลแบบ any หรือ unknown จนสูญเสียความปลอดภัยไปในที่สุด

ความชัดเจนที่หายไปในภาษาอื่น

จุดเริ่มต้นของความหงุดหงิดในภาษาอื่นคือการขาดหายไปของความชัดเจน ในมุมมองของเขา ฟังก์ชันใน Rust เป็นสิ่งที่งดงามมาก เพียงแค่มองปร๊าดเดียวที่ Signature ของฟังก์ชัน เราก็รู้ทันทีว่ามันรับพารามิเตอร์แบบไหน คืนค่าเป็นอะไร และที่สำคัญที่สุดคือ “มันมีโอกาสล้มเหลวในรูปแบบไหนบ้าง” ผ่านประเภทข้อมูล Result การออกแบบนี้ทำให้เรามั่นใจได้ว่าฟังก์ชันจะไม่เกิดการแครชแบบคาดเดาไม่ได้ (Unpredictable panic) ทุกความผิดพลาดจะถูกส่งต่อความรับผิดชอบขึ้นไปหา Caller อย่างเป็นระบบและตรวจสอบได้เสมอว่าพังที่ไหนและเพราะอะไร ซึ่งสิ่งเหล่านี้ TypeScript ไม่มีให้ใช้เลยตั้งแต่แกะกล่อง

ความพยายามจำลองสถาปัตยกรรมด้วย neverthrow

เมื่อความคุ้นเคยจาก Rust หายไป เขาจึงพยายามจำลองสถาปัตยกรรมนี้ใน TypeScript ผ่านไลบรารีที่ชื่อว่า neverthrow เป้าหมายแรกคือการสร้างประเภทข้อมูล Error ของตัวเองและบังคับใช้เป็นมาตรฐานกลางของแอปพลิเคชัน เพื่อให้ทุกฟังก์ชันจัดการ Error ไปในทิศทางเดียวกัน แต่ความเจ็บปวดที่แท้จริงของการย้ายข้ามภาษาคือการไม่มีเครื่องหมาย ? (Question mark operator) ใน Rust เราสามารถเชื่อมต่อฟังก์ชันที่คืนค่า Result ได้อย่างลื่นไหล ตัวคอมไพเลอร์จะจัดการเรื่องการแปลงชนิดของ Error และทำ Early return ให้โดยอัตโนมัติ แต่ใน TypeScript เมื่อไม่มีเครื่องหมายนี้ นักพัฒนาจะต้องมาเขียนโค้ดเพื่อแกะค่า (Unwrap) ออกมาตรวจเช็คเองแบบแมนนวลด้วยคำสั่ง if (result.isErr()) แล้วค่อย throw ออกไป ซึ่งทำให้โค้ดบวมและเสียสมาธิในการอ่าน Logic หลัก

ความซับซ้อนของ Generator Functions และ Overhead

ตรงนี้แหละครับที่เป็นจุดไคลแม็กซ์ทางเทคนิค เพื่อที่จะก้าวข้ามข้อจำกัดและจำลองพฤติกรรมการทำงานของเครื่องหมาย ? ทางฝั่ง TypeScript จำเป็นต้องงัดเอาท่าที่ค่อนข้างลึกอย่าง “Generator Functions” มาใช้ (การใช้ function* ร่วมกับคำสั่ง yield*) โดยการสร้างฟังก์ชันห่อหุ้มที่ชื่อ safeTry เพื่อดักจับว่าหากเกิด Error ขึ้น ตัว yield* จะทำการหยุดการทำงานของฟังก์ชันนั้นทันที (Short-circuit) และดัน Error ขึ้นไปด้านบน ท่านี้แม้จะช่วยให้โค้ดดูใกล้เคียงกับการ Chain ฟังก์ชันแบบ Rust มากที่สุด แต่มันก็แลกมาด้วยต้นทุนมหาศาลเบื้องหลัง เพราะ Generator ใน JavaScript หมายถึงการสร้าง Object ขึ้นมาในหน่วยความจำและมีภาระการทำงาน (Overhead) ในช่วงรันไทม์

Zero-Cost Abstraction ของ Rust

เมื่อเรามองย้อนกลับมาที่ Rust จะเห็นเลยว่าเครื่องหมาย ? ของเรานั้นเป็น “Zero-Cost Abstraction” อย่างแท้จริง มันถูกแปลผลตั้งแต่ระดับ AST (Abstract Syntax Tree) ตอนคอมไพล์โค้ดให้กลายเป็นเพียงโครงสร้าง match ธรรมดา เราได้ความสง่างามในการจัดการ Error โดยไม่ต้องเสียประสิทธิภาพการทำงานในตอนรันไทม์เลยแม้แต่น้อย

ต้นทุนของการจำลองด้วย Framework ขนาดใหญ่

Abid Omar ยังได้พูดถึงความพยายามของฝั่ง TypeScript ที่จะไปให้สุดทางด้วยการใช้เฟรมเวิร์กขนาดใหญ่อย่าง Effect ที่พ่วงมาทั้งระบบจัดการ Error แบบระบุชนิดข้อมูล (Typed errors) และระบบติดตามการทำงานที่ซับซ้อน แต่แน่นอนว่ามันต้องแลกมาด้วยความยากในการเรียนรู้ที่สูงลิ่ว และต้องรื้อโครงสร้างโค้ดใหม่ทั้งหมด ซึ่งเป็นการเตือนสติที่ดีว่า เฟรมเวิร์กที่ยัดเยียดฟีเจอร์มาให้เยอะๆ มักมีราคาที่ต้องจ่ายเสมอโดยเฉพาะตอนรันไทม์

บทสรุป: คุณค่าที่แท้จริง

เรื่องราวนี้ทำให้เราในฐานะ Rust Developer ยิ่งเห็นคุณค่าของภาษาที่เราใช้ การที่ Rust ออกแบบให้การจัดการ Error เป็นโครงสร้างพื้นฐานของภาษา (Language Primitive) ที่ฝังลึกระดับคอมไพเลอร์ มันได้ช่วยปกป้องเราจากบั๊กที่ซ่อนเร้น ให้ประสิทธิภาพสูงสุด และสร้างมาตรฐานเดียวกันให้กับทั้งระบบนิเวศ โดยไม่ต้องพึ่งพาไลบรารีที่หนักหน่วงเลย …

Credit & Reference:

  1. Rust-like Error Handling in TypeScript
  2. neverthrow GitHub repo
  3. effect GitHub repo

ทำความรู้จัก Smart Pointer

📅 วันที่เผยแพร่: 2026-03-05

การจัดการหน่วยความจำในภาษา Rust เปรียบเสมือนการเดินทางที่เริ่มจากรากฐานที่เรียบง่ายที่สุด นั่นคือการทำความเข้าใจ Stack และ Heap โดยเครื่องมือชิ้นแรกที่เราต้องรู้จักคือ Box<T> ซึ่งทำหน้าที่เป็นสมาร์ทพอยน์เตอร์ (Smart Pointer) พื้นฐานในการจองพื้นที่บน Heap สถาปัตยกรรมนี้มอบสิทธิการครอบครองข้อมูลแบบเจ้าของคนเดียว (Single Ownership) โดยไม่มีภาระการประมวลผลส่วนเกิน (Overhead) ตอนรันไทม์ ทำให้เหมาะอย่างยิ่งสำหรับข้อมูลที่มีขนาดไม่แน่นอนตอนคอมไพล์ หรือการสร้างโครงสร้างข้อมูลแบบ Recursive types อย่างไรก็ตาม เมื่อโปรแกรมมีความซับซ้อนขึ้นและต้องการให้ข้อมูลชุดเดียวมี “เจ้าของหลายคน” ลำพังเพียงแค่ Box จึงไม่สามารถตอบโจทย์ได้อีกต่อไป

กลไกการครอบครองร่วม: Rc และ Arc

เพื่อทลายข้อจำกัดดังกล่าว Rust จึงมีกลไกการครอบครองร่วม (Shared Ownership) ผ่านการนับจำนวนตัวอ้างอิง หากทำงานในสภาพแวดล้อมแบบเธรดเดียว เราสามารถใช้ Rc<T> ได้ แต่เมื่อก้าวเข้าสู่โลกของการทำงานพร้อมกันหลายเธรด (Concurrency) เราจำเป็นต้องพึ่งพา Arc<T> (Atomic Reference Counting) เพื่อรับประกันความปลอดภัยข้ามเธรด กลไกของ Arc จะคอยนับจำนวนเจ้าของและทำลายข้อมูลทิ้งอัตโนมัติเมื่อไม่มีใครใช้งาน ทว่ากฎเหล็กของการแชร์ข้อมูลใน Rust คือข้อมูลนั้นจะถูกบังคับให้อ่านได้อย่างเดียว ดังนั้น หากเราต้องการเข้าไปเปลี่ยนแปลงหรือแก้ไขข้อมูลที่ถูกแชร์อยู่ เราจึงต้องอาศัยเทคนิคการแก้ไขข้อมูลจากภายใน (Interior Mutability) เข้ามาประกอบด้วย

การแก้ไขข้อมูลข้ามเธรด: Mutex และ RwLock

การแก้ไขข้อมูลที่แชร์ข้ามเธรดอย่างปลอดภัยมักใช้สถาปัตยกรรมคู่หู นั่นคือการนำ Arc มาครอบ Mutex (Arc<Mutex<T>>) โดย Arc จะคอยจัดการเรื่องวงจรชีวิตของข้อมูล ส่วน Mutex จะทำหน้าที่เป็นประตูกลที่ยอมให้ทีละเธรดเข้าไปแก้ไขข้อมูลได้เท่านั้น เพื่อป้องกันปัญหาข้อมูลชนกัน แต่หากระบบงานของเราเน้นการอ่านเป็นหลัก (Read-heavy) การใช้ RwLock จะช่วยรีดประสิทธิภาพได้ดีกว่า เพราะอนุญาตให้หลายเธรดอ่านข้อมูลพร้อมกันได้อิสระ และจะทำการล็อกแบบผูกขาดก็ต่อเมื่อมีการเขียนเท่านั้น

กลไกความปลอดภัยและ Poisoned Lock

นอกจากนี้ Rust ยังมีกลไกความปลอดภัยขั้นสูง หากเธรดเกิดพังทลาย (Panic) ขณะกำลังถือล็อก ระบบจะทำการแจ้งเตือนว่าล็อกนั้น “ติดพิษ” (Poisoned) เพื่อยับยั้งไม่ให้เธรดอื่นนำข้อมูลที่อาจไม่สมบูรณ์ไปประมวลผลต่อ

ล็อกระดับฮาร์ดแวร์และเทคนิคขั้นสูง

เมื่อความเร็วในการทำงานคือเป้าหมายสูงสุด การใช้ล็อกที่พึ่งพาระบบปฏิบัติการอาจทำให้เกิดคอขวด Rust จึงเปิดประตูสู่การทำงานระดับฮาร์ดแวร์ด้วย Atomics ซึ่งใช้คำสั่งโดยตรงของ CPU ช่วยให้ปรับแก้ค่าตัวเลขได้รวดเร็วแบบไม่ต้องมีการล็อก (Lock-free) นอกจากนี้ยังมีเทคนิคทางเลือกเพื่อรีดประสิทธิภาพ เช่น การใช้ Scoped Threads ที่อนุญาตให้เธรดลูกดึงข้อมูลจาก Stack ของเธรดแม่ไปใช้ได้โดยตรงเพื่อลด Overhead ของ Arc ไปจนถึงการใช้โครงสร้างข้อมูลขั้นสูงอย่าง DashMap หรือ Crossbeam สำหรับระบบสเกลขนาดใหญ่

ท้ายที่สุดแล้ว หัวใจสำคัญของการประยุกต์ใช้สมาร์ทพอยน์เตอร์ใน Rust คือการไต่ระดับอย่างชาญฉลาด โดยเริ่มจากเครื่องมือที่เรียบง่ายและปลอดภัยที่สุด แล้วจึงค่อยๆ ปรับไปใช้สถาปัตยกรรมที่ซับซ้อนขึ้นเพื่อรักษาสมดุลระหว่างประสิทธิภาพและความถูกต้องของระบบอย่างสมบูรณ์แบบในที่สุด

Credit & Reference:

  1. A Guide to Rust Smart Pointers

สถาปัตยกรรม Compilation Pipeline ของ Rust

📅 วันที่เผยแพร่: 2026-02-22

สำหรับ Rust Developer การสั่ง cargo build เพื่อให้ได้ Executable file ที่ทำงานได้รวดเร็วและปลอดภัยแบบ Memory-safe โดยไม่ต้องอาศัย Garbage Collector ถือเป็นเรื่องปกติในชีวิตประจำวัน แต่ภายใต้กระบวนการนั้น สถาปัตยกรรมของ rustc (Rust Compiler) ถูกออกแบบมาอย่างเป็นระบบผ่าน Multi-stage Pipeline ที่ทำหน้าที่ตรวจสอบโค้ดอย่างเข้มงวดในแต่ละระดับ ก่อนหน้านี้มี topic compiler ช้า งั้นเรามาดูว่า Source Code ของเราผ่านกระบวนการอะไรบ้างกว่าจะกลายเป็น Machine Code เพื่อจะได้เห็นภาพว่า Compiler ทำอะไรบ้าง

Front-end: Parsing และ AST

กระบวนการเริ่มต้นที่ระดับ Front-end Compiler จะรับ Raw text code เข้ามาทำกระบวนการ Parsing โดยแยกแยะองค์ประกอบออกเป็น Tokens (เช่น Keywords และ Identifiers ต่างๆ) จากนั้นนำมาจัดเรียงเป็นโครงสร้าง Abstract Syntax Tree (AST) ในขั้นตอนนี้ Compiler จะจัดการกับ Expansion ด้วย เช่น การขยาย Macros หรือการทำ Desugaring โครงสร้างอย่าง for-loops ให้อยู่ในรูปแบบที่ Compiler จัดการได้ง่ายขึ้น

Lowering to HIR (High-Level Intermediate Representation)

เนื่องจาก AST ยังยึดติดกับรูปแบบ Syntax ของ Source code มากเกินไป rustc จึงทำการ “Lower” (ลดระดับโครงสร้าง) AST ลงมาเป็น High-Level Intermediate Representation (HIR) ใน State นี้ Compiler จะเริ่มทำ Semantic Analysis เบื้องต้น ได้แก่ Name Resolution เพื่อสแกนหาและระบุตัวแปรหรือฟังก์ชันทั้งหมดใน Scope และ Type Checking ซึ่งจะตรวจสอบความถูกต้องของการใช้งาน Types หากมี Typo หรือ Type Mismatch จะถูก Report Error ตั้งแต่ขั้นตอนนี้

หัวใจสำคัญ: MIR (Mid-Level Intermediate Representation)

เมื่อผ่านการตรวจสอบเบื้องต้น HIR จะถูก Lower ลงอีกขั้นกลายเป็น Mid-Level Intermediate Representation (MIR) ซึ่งออกแบบมาเฉพาะสำหรับการทำ Complex Analysis MIR คือหัวใจสำคัญของ Rust เพราะมันทำหน้าที่เป็น Input หลักให้กับ Borrow Checker ในขั้นตอนนี้ rustc จะบังคับใช้กฎ Ownership, Borrowing และ Lifetimes อย่างเคร่งครัด

นอกจากนี้ยังมีกระบวนการ Lifetime Elision ที่ Compiler จะพยายามอนุมาน (Infer) ความสัมพันธ์ของ Lifetime โดยอัตโนมัติ เพื่อลดภาระการเขียน Generic Lifetime Annotations ที่ไม่จำเป็น การวิเคราะห์แบบ Static ในระดับ MIR นี้เอง ที่ทำให้ Rust สามารถป้องกันปัญหา Dangling References และการันตี Memory Safety ได้ตั้งแต่ตอน Compile

Backend: LLVM IR และ Optimization

เมื่อ Code ผ่าน Verification ด้านความปลอดภัยทั้งหมดจาก MIR แล้ว rustc จะทำหน้าที่ประหนึ่ง Front-end ที่ส่งต่อหน้าที่ให้กับ Backend อย่าง LLVM MIR จะถูกแปลงไปเป็น LLVM IR (Intermediate Representation ของ LLVM) จากนั้น LLVM จะทำหน้าที่รัน Optimization Passes จำนวนมาก เพื่อปรับแต่งโครงสร้างโค้ดให้ทำงานได้รวดเร็วและใช้ทรัพยากรอย่างมีประสิทธิภาพที่สุด (นี่คือเหตุผลหลักของ Performance ในโปรแกรม Rust) ท้ายที่สุด LLVM จะแปล Optimized IR ให้กลายเป็น Machine Code (Object code) ที่เฉพาะเจาะจงกับ Architecture ของเครื่องปลายทาง

Linking: ขั้นตอนสุดท้ายสู่ Final Executable

ในขั้นตอนสุดท้าย Linker จะรับ Object code ที่ถูกสร้างขึ้น นำมาประกอบ (Bundle) รวมกับ Libraries อื่นๆ ที่เกี่ยวข้อง (เช่น ไฟล์ Archive .rlib จาก dependencies ต่างๆ) เพื่อประกอบออกมาเป็น Final Executable ที่สมบูรณ์พร้อมทำงาน

Summary Pipeline

Cargo ➔ rustc ➔ AST ➔ HIR (Type Checking) ➔ MIR (Borrow Checking) ➔ LLVM IR ➔ Optimization ➔ Executable

บทสรุป

จาก Pipeline ทั้งหมด จะเห็นได้ว่า Rust ถูกออกแบบมาให้เป็นมากกว่าแค่ภาษาโปรแกรม แต่มันคือ “Rigorous Verification System” หรือระบบตรวจสอบแบบรัดกุม ที่บังคับให้โค้ดต้องปลอดภัย 100% ตั้งแต่ตอน Compile

ในมุมมองของ Architecture การที่ rustc แยก State ของ Intermediate Representation (HIR/MIR) ออกจากกันอย่างชัดเจน ช่วยให้การจัดการกับ Control-flow graph สำหรับ Borrow Checker ทำได้โดยอิสระ ก่อนที่จะโยนภาระหนักเรื่อง Optimization ไปให้ LLVM

Credit & Reference:

  1. Understanding Rust Complier
  2. Overview of the compiler

บางครั้ง Benchmark ไม่ได้วัดแค่ความเร็ว แต่กำลังเผยให้เราเห็นถึงปรัชญาของภาษานั้นๆ

📅 วันที่เผยแพร่: 2026-02-18

หากเรามองเผิน ๆ การทดสอบนี้ดูเหมือนเป็นเพียงการเปรียบเทียบความเร็วในการประมวลผลระหว่างหลายภาษา อาทิ C, C++, Go และ Rust โดยให้แต่ละภาษาทำงานเดียวกัน คือคำนวณผลรวมของกำลังสองของจำนวนเต็มตั้งแต่ 1 ถึง 100 ล้าน โดยแบ่งงานออกเป็น 4 เธรด โค้ดของทุกภาษามีโครงสร้างแทบจะเหมือนกันทั้งหมด ทั้งการแบ่งช่วงตัวเลข การวนลูปคำนวณ และการนำผลลัพธ์จากแต่ละเธรดมารวมกัน ซึ่งผลลัพธ์ที่ถูกต้องคือ “672,921,401,752,298,880” Rust ดูเหมือนจะสอบตก คำนวณก็ช้า…. แถมได้ผลลัพธ์ที่ออกมาก็ผิดอีก

ปัญหาซ่อนเร้นเมื่อตัวเลขเกินขีดจำกัด

แต่เมื่อพิจารณาให้ลึกลงไป การทดสอบนี้กลับเผยให้เห็นสิ่งที่สำคัญกว่าความเร็ว นั่นคือแนวคิดพื้นฐานของแต่ละภาษาในการจัดการกับ ความถูกต้องของตัวเลขและความรับผิดชอบของผู้พัฒนา

ปัญหาที่ซ่อนอยู่ในโจทย์นี้คือ ขนาดของตัวเลขที่ใช้ในการคำนวณ แม้ว่าค่าแต่ละพจน์ ( i^2 ) จะยังอยู่ในขอบเขตของจำนวนเต็ม 64 บิต แต่เมื่อเริ่มนำค่าจำนวนมากมาสะสมรวมกัน ผลรวมสุดท้ายได้ข้ามขีดจำกัดนั้นไปแล้วโดยไม่รู้ตัว จุดนี้เองที่ทำให้ภาษาต่าง ๆ แสดง “บุคลิก” ของตนออกมาอย่างชัดเจน ทั้งที่โจทย์และโค้ดดูเหมือนจะเหมือนกันทุกประการ

แนวทางของ C, C++ และ Go

ในฝั่งของ C และ C++ การใช้ long long ทำให้เกิด signed integer overflow ซึ่งตามมาตรฐานของภาษาแล้วถือเป็น พฤติกรรมที่ไม่ถูกกำหนดให้แน่ชัด (undefined behavior) นั่นหมายความว่า compiler สามารถเลือกทำอะไรก็ได้กับโค้ดชุดนี้ ผลลัพธ์ที่ได้ออกมาดูเหมือนจะถูกต้องก็จริง แต่ความถูกต้องนั้นเกิดจากความบังเอิญ? ไม่ใช่สิ่งที่ภาษาให้การรับรอง การไม่มีคำเตือนหรือ error จึงไม่ได้แปลว่าโค้ดนั้นปลอดภัยหรือถูกต้องตามหลักคณิตศาสตร์

Go เลือกแนวทางที่ต่างออกไป ด้วยการใช้ uint64 ซึ่งกำหนดพฤติกรรมของ overflow ไว้อย่างชัดเจนให้เป็นการวนรอบ (wrap-around) ตามโมดูลัส (2^64) โปรแกรมจึงรันจนจบและให้ผลลัพธ์ที่ดูเสถียรโดยไม่มีการแจ้งเตือนใด ๆ อย่างไรก็ตาม ความถูกต้องของผลลัพธ์ในกรณีนี้ขึ้นอยู่กับความเข้าใจของผู้พัฒนาล้วน ๆ ภาษาไม่ได้บังคับให้หยุดคิดว่าตัวเลขที่ได้ยังคงมีความหมายทางคณิตศาสตร์หรือไม่

เส้นทางของ Rust ที่ไม่ยอมให้ผ่านไปเงียบๆ

Rust กลับเลือกเดินคนละเส้นทางอย่างชัดเจน ภาษาไม่ยอมให้การ overflow ผ่านไปแบบเงียบ ๆ โดยไม่ตั้งคำถาม เมื่อใช้ชนิดข้อมูล 64 บิต การคำนวณนี้จะถูกจับได้ทันที ในโหมด debug โปรแกรมจะหยุดทำงาน ส่วนในโหมด release จะเกิดการ wrap แต่ก็เป็นผลจากการตัดสินใจของผู้พัฒนาเอง หากต้องการผลลัพธ์ที่ถูกต้องจริง ผู้พัฒนาจำเป็นต้องระบุชนิดข้อมูลที่ใหญ่พอ เช่น u128 อย่างชัดเจน

จุดนี้สะท้อนว่า Rust ปฏิเสธที่จะ “เดาแทนผู้พัฒนา” ว่าการ overflow นั้นยอมรับได้หรือไม่ เมื่อเลือกชนิดข้อมูลได้ถูกต้องแล้ว Rust จะให้ผลลัพธ์ทางคณิตศาสตร์ที่ตรงกับความจริง โดยไม่พึ่งพา undefined behavior หรือการ wrap แบบเงียบ ๆ

ปรัชญาการออกแบบผ่าน Benchmark

การทดสอบจึงไม่ใช่การแข่งขันเรื่องความเร็วอีกต่อไป แต่เป็นภาพสะท้อนของปรัชญาการออกแบบภาษาอย่างชัดเจน C และ C++ ให้อิสระสูงสุดแก่ผู้พัฒนาโดยแลกกับการรับประกันความถูกต้อง Go เน้นความเรียบง่ายและความคาดเดาได้ แม้จะยอมให้ข้อผิดพลาดเชิงตัวเลขผ่านไปได้ ส่วน Rust เลือกให้ความสำคัญกับความถูกต้องและความชัดเจนของเจตนาผู้พัฒนาเป็นอันดับแรก แม้จะทำให้โค้ดดูเข้มงวดขึ้นในตอนแรกก็ตาม

มาถึงตรงนี้ benchmark นี้ไม่ได้แสดงให้เห็นว่า Rust ด้อยประสิทธิภาพกว่าใคร แต่แสดงให้เห็นว่า Rust เลือกไม่แลกความถูกต้องกับความสะดวก และเมื่อระบบถูกกดดันด้วยขนาดของข้อมูล ความแตกต่างเชิงปรัชญานี้เองที่ปรากฏออกมาอย่างเด่นชัด แต่ละภาษาก็มีความงดงามของตนเอง ว่าแต่คุณทำไมถึงเลือกเขียน Rust ลองตอบคำถามนี้ดูครับ

Credit & Reference:

  1. A Compiled Review
  2. Concurrency benchmark computing sum of squares in C, C++, Rust, and Go

Rust Crates

[Rust Crates] List Crates ที่น่าจับตามองที่สุดในปี 2025 ที่ผ่านมา

📅 วันที่เผยแพร่: 2026-02-28

เรามักจะได้ยินคำแนะนำว่า “You should switch to Rust” กันจนชินหู แต่ในปี 2025 ที่ผ่านมา เหตุผลของการย้ายมาใช้ Rust ไม่ใช่แค่เรื่อง Memory Safety อีกต่อไป แต่มันคือเรื่องของ Ecosystem Maturity ที่ก้าวไปถึงจุด Peak Performance

ผมได้สรุปรายการ Must-Know Crates จาก Engineering Team ของ Freestyle มาวิเคราะห์เจาะลึกในมุมมองเชิงสถาปัตยกรรม (Architecture) และ System Programming ว่าทำไมไลบรารีเหล่านี้ถึงน่าจับตามอง ที่ Rust Developer ทุกคนควรมีติด Toolbelt ไว้ครับ

1. Architecture & Codebase Management

การจัดการ Codebase ที่ดีเริ่มต้นที่ Type System และ Environment ที่แข็งแกร่ง

  • TestContainers (Integration as Code): ลืมการเขียน Shell Script เพื่อ Spin-up Database หรือการ Mocking ที่ไม่สมจริงไปได้เลย TestContainers นำแนวคิด “Ephemeral Infrastructure” มาสู่ Rust Unit Tests โดยตรง มันช่วยให้เรากำหนด Docker Containers (Postgres, Redis, Kafka etc.) เป็น Rust Code ได้เลย เราสามารถรัน Integration Tests บน CI environment ที่สะอาดและเหมือน Production จริงๆ ได้โดยไม่ต้อง setup ภายนอก
  • Bon (Compile-Time Builder Pattern): การเขียน Builder Pattern ด้วยมือคือ Boilerplate มหาศาล Bon แก้ปัญหานี้ด้วย Derive Macro ที่ใช้พลังของ Type-level Programming ขั้นสูง จุดเด่นคือ Compile-time guarantees ถ้าเราลืม set required field ตัว Compiler จะด่าเราทันที ไม่ต้องรอลุ้นตอน Runtime API ที่เจนออกมามีความ Ergonomic สูงมาก รองรับ Optional และ Default values ได้เนียนกริบ
  • Strum (Enum Superpowers): Rust Enums คือ Algebraic Data Types ที่ทรงพลัง แต่การจัดการกับ String มักจะยุ่งยาก Strum เข้ามาเติมเต็มส่วนนี้ด้วย Macro EnumIter (วนลูป Enum) และ EnumString (แปลง String <-> Enum) ลดการเขียน match case ซ้ำซ้อนลงไปได้มหาศาล
  • DotEnvy (The Secure Successor): ใครที่ยังใช้ crate dotenv อยู่ ขอให้รู้ว่ามัน Unmaintained และมีปัญหา (ใครใช้ AI ระวังมันชอบใช้ dotenv) DotEnvy คือ Fork ที่ได้รับการดูแลอย่างถูกต้อง เพื่อการโหลด Environment Variables ที่ปลอดภัยและเสถียรกว่าสำหรับการทำ 12-Factor

2. Low-Level Mastery & Data Layout

เมื่อเราต้องการคุยกับ Hardware หรือจัดการ Memory Layout แบบ Byte-perfect

  • Bytemuck (Safe Zero-Copy): หัวใจสำคัญของงาน High-performance (Graphics, GPU, Network) Bytemuck ช่วยให้เราทำ “Zero-copy casting” ระหว่าง Types ได้อย่างปลอดภัย แทนที่จะใช้ unsafe ดิบๆ Bytemuck ใช้ Trait Bounds (Pod, Zeroable) เพื่อการันตีว่า Memory Layout นั้นเข้ากันได้จริง (Same size/alignment) ทำให้การส่งข้อมูลดิบไป GPU หรือ Network Buffer ปลอดภัยหายห่วง
  • Papaya (Lock-Free Concurrency): ทุกคนรู้จัก DashMap (Sharded Locking) แต่ถ้า Workload ของคุณมี Contention สูงมาก การรอ Lock คือหายนะ Papaya คือ Lock-free Concurrent Map ที่ใช้ Atomic Operations และเทคนิค Deferred Memory Reclamation ที่แลกมาด้วย “Mild Eventual Consistency” (อาจอ่านเจอค่าที่เพิ่งถูกลบไปเสี้ยววินาที) แต่ได้ Throughput ที่สูงลิ่ว และ Incremental Resizing ที่ไม่ Block Thread เหมาะกับระบบที่ Latency-sensitive สุดๆ
  • Lock_api (Abstraction Layer): Library ที่หาตัวจับยากในภาษาอื่น Lock_api ไม่ได้ implement lock เอง แต่เป็นคนกำหนด Traits มาตรฐานสำหรับ Lock implementation ต่างๆ และช่วยให้เราเขียน Code ที่ Agnostic ต่อ Lock implementation (จะใช้ parking_lot หรือ std::sync) ก็สลับได้ทันทีโดยไม่ต้องแก้ Business Logic

3. Metaprogramming & Macros

ลด Boilerplate และเพิ่ม Compile-time capabilities

  • Darling (Declarative Proc-Macros): การเขียน proc-macro เพื่อ Parse TokenStream เองคืองานกรรมกร Darling เปลี่ยนมันให้เป็น Declarative style ช่วย Parse attributes และ meta items ให้เป็น Struct สวยงาม ทำให้การเขียน Custom Derive เป็นเรื่องสนุกขึ้นเยอะ
  • Inventory (Global Registry Pattern): เคยอยากลงทะเบียน Plugin หรือรวบรวม instances ของ Struct ที่กระจายอยู่หลายไฟล์มารวมกันตอน Compile time ไหม? Inventory ใช้เทคนิคระดับ Linker section (คล้าย Constructor function ใน C++) เพื่อทำ Compile-time Collection เหมาะมากสำหรับการทำ Plugin System หรือ Registry pattern

4. Documentation & Communication

การสื่อสารที่มี Contract ชัดเจนและ Type-safe

  • Utoipa (Code-First OpenAPI): เลิกเขียน YAML แยกได้แล้ว Utoipa ใช้ Proc-macros ดึง Metadata จาก Rust Code ไป Gen OpenAPI (Swagger) Spec โดยตรง Integrate กับ Axum ได้สมบูรณ์แบบ ทำให้ Documentation ไม่เคย Out-of-sync กับ Code
  • Tarpc (Rust-Native RPC): ถ้าทั้ง Client และ Server เป็น Rust ทำไมต้องแบกภาระของ gRPC? Tarpc คือ RPC Framework ที่เบาและ Type-safe สุดๆ Transport agnostic จะรันบน TCP, Unix Sockets หรือแม้แต่ In-memory Channel (สำหรับการสื่อสารระหว่าง Thread) ก็ทำได้ง่ายมาก
  • Schemars (JSON Schema Gen): Generate JSON Schema จาก Rust Structs ที่ Compile time สิ่งนี้สำคัญมากสำหรับการทำ Contract Testing กับ Frontend หรือ External Systems เพื่อยืนยันว่าโครงสร้างข้อมูลตรงกันเสมอ

5. Parsing & Visualization

  • Chumsky (User-Centric Parser): Parser Combinator ที่ยอมแลก Performance เล็กน้อย (แต่ยังเร็ว) เพื่อแลกกับ Error Recovery และ Error Message ที่มนุษย์อ่านรู้เรื่อง Use Case เหมาะมากสำหรับการเขียน Compiler, Interpreter หรือ DSL ที่ต้องการบอก User ว่า “ผิดตรงไหนและควรแก้อย่างไร” ไม่ใช่แค่โยน Error code ออกมา
  • Hexplay (Binary Visualization): Debugger สำหรับคนทำงานสาย Protocol แสดงข้อมูล Binary ในรูปแบบ Hex Editor พร้อมสีสันและการจัด Format ที่ Config ได้ ช่วยลดความปวดหัวเวลาแกะ Binary Packet ได้มหาศาล

6. Interop & Extending Boundaries

เมื่อ Rust ต้องคุยกับโลกภายนอก

  • MLua (Scripting Engine): High-level binding สำหรับ Lua (รองรับ LuaJIT/Luau) ที่ปลอดภัย จุดเด่นคือรองรับ Async/Await ทำให้เราเขียน Script Logic แบบ Non-blocking ผสานกับ Rust Async Runtime ได้เลย
  • V8 (JavaScript Runtime): รัน JavaScript Isolates ใน Rust (แบบเดียวกับที่ Deno ทำ) ให้เราควบคุม Event Loop และ V8 Platform ได้ลึกถึงระดับรากฐาน
  • WGPU (Graphics & Compute): นี่คืออนาคตของ Graphics Programming WGPU คือ Implementation ของ WebGPU spec ที่ Production Ready แล้ว การเขียน Compute Shaders บน WGPU ให้ประสบการณ์ที่ดีกว่า C++ ในหลายมิติ และเป็น Cross-platform abstraction (Vulkan/Metal/DX12) ที่ดีที่สุดในตอนนี้

7. Infrastructure & Embedded

  • Hickory (Full-Stack DNS): DNS Server และ Resolver ที่เขียนด้วย Rust 100% ปลอดภัยจาก Memory Vulnerabilities เดิมๆ ที่มักเจอใน BIND หรือ C-based DNS implementation
  • Embassy (Async Embedded): The Revolution is here Embassy คือ Framework ที่ทำให้เรารัน Async Rust บน Microcontroller (ESP32, STM32, RPi Pico) ได้โดย ไม่ต้องมี OS เปลี่ยนโลก Embedded ให้เขียนง่ายเหมือนเขียน Backend Services จัดการ Hardware Interrupts ด้วย Async/Await ได้อย่างสวยงาม

List นี้สะท้อนให้เห็นว่า Rust Community ในปี 2025 ที่ผ่านมา ไม่ได้หยุดอยู่แค่ความปลอดภัย แต่เน้นไปที่ Developer Experience (DX) และ Performance Optimization ในระดับสถาปัตยกรรม เครื่องมือเหล่านี้คือสิ่งที่ทำให้ Rust กลายเป็นภาษาที่ “Complete” ที่สุดภาษาหนึ่งในยุคปัจจุบัน หวังว่าจะเป็นประโยชน์และได้ไอเดียไปปรับใช้กับโปรเจกต์ของทุกท่านครับ

อัปเดตนโยบายแจ้งเตือน Malicious Crate บน crates.io

📅 วันที่เผยแพร่: 2026-02-14

ทีม crates.io ได้ประกาศเปลี่ยนแปลงนโยบายการแจ้งเตือน malicious crate โดยจะไม่มีการเขียนบล็อกโพสต์ทุกครั้งที่พบหรือได้รับรายงาน crate ที่เป็นอันตราย เนื่องจากในกรณีส่วนใหญ่ที่ผ่านมาไม่พบหลักฐานการใช้งานจริง การโพสต์แจ้งทุกครั้งจึงกลายเป็น noise มากกว่าจะเป็นสัญญาณเตือนที่เป็นประโยชน์

การแจ้งเตือนผ่าน RustSec Advisory

อย่างไรก็ตาม เมื่อมีการลบ crate ที่มี malware ทางทีมจะเผยแพร่ RustSec advisory เสมอ สามารถติดตามได้ผ่าน RSS feed ของ RustSec ส่วนกรณีที่ crate นั้นมีการใช้งานจริงหรือมีการโจมตีจริง ทางทีมจะยังคงเผยแพร่ทั้งบล็อกโพสต์และ RustSec advisory พร้อมอาจมีการแจ้งผ่านช่องทางเพิ่มเติม เช่น social media หากเห็นสมควร

กรณีศึกษา Malicious Crates ล่าสุด

สำหรับ malicious crates ที่ถูกลบล่าสุดตั้งแต่โพสต์ก่อนหน้าจนถึงปัจจุบัน ได้แก่ finch_cli_rust, finch-rst และ sha-rst ซึ่งถูกรายงานเมื่อวันที่ 9 ธันวาคม 2025 ว่าพยายามขโมย credentials โดยปลอมตัวเป็น crate finch และ finch_cli (RUSTSEC-2025-0150 ถึง 0152)

ต่อมาวันที่ 6 กุมภาพันธ์ polymarket-clients-sdk ถูกรายงานว่าพยายามขโมย credentials โดยปลอมตัวเป็น polymarket-client-sdk (RUSTSEC-2026-0010) และล่าสุดวันที่ 13 กุมภาพันธ์ polymarket-client-sdks ก็ถูกรายงานในลักษณะเดียวกัน (RUSTSEC-2026-0011) ทุกกรณีมีการลบ crate ปิดการใช้งานบัญชีผู้เผยแพร่ทันที และรายงานไปยัง upstream providers ที่เกี่ยวข้องแล้ว

Credit & Reference:

  1. crates.io: an update to the malicious crate notification policy

Rust Games

ยังไม่มีบทความในหมวดหมู่นี้

Rust Hacker

ยังไม่มีบทความในหมวดหมู่นี้

Rust Project

“sabiql” TUI ที่ไม่ง้อ Database Driver

📅 วันที่เผยแพร่: 2026-03-06

สำหรับใครที่เป็นสาย terminal แล้วทำงานกับ PostgreSQL ทุกวัน คงเคยผ่านความรู้สึกนี้มาแล้ว เปิด DBeaver รอ splash screen โหลด กดคลิกผ่านหน้าต่างซ้อนหน้าต่าง แล้วก็วนกลับมาที่ psql เหมือนเดิม เพราะมันเร็วกว่า riii111 ก็เจอปัญหานี้เหมือนกัน เลยตัดสินใจสร้าง sabiql ขึ้นมาเอง TUI สำหรับ browse, query และ edit PostgreSQL เขียนด้วย Rust + Ratatui โดยมีหลักการง่ายๆ ว่า ถ้ามี psql อยู่ในเครื่องแล้ว ก็ควรจะรันได้เลย ไม่ต้องติดตั้ง database driver หรือ config connection pool เพิ่มอีกแม้แต่นิดเดียว

สถาปัตยกรรม Driver-less และการจัดการ Overhead

แนวคิดที่ทำให้ “sabiql” แตกต่างจาก TUI tool อื่นคือสถาปัตยกรรม driver-less อย่างแท้จริง แทนที่จะ link กับ libpq โดยตรง มันเลือก spawn psql เป็น subprocess สำหรับทุก query เลย trade-off ที่ตามมาคือ spawn overhead สะสมเร็วมาก implementation แรกของ auto-completion engine รัน 6 queries ต่อตาราง ฐานข้อมูลที่มี 538 ตารางนั่นหมายถึง 3,228 psql spawns แค่ตอน startup เดียว CPU spike ขึ้น 3-5 วินาที

วิธีแก้คือ consolidate เป็น query เดียวที่ดึงเฉพาะ columns กับ FK ที่ใช้จริง แล้วเสริมด้วย two-tier caching Tier 1 เป็น TTL cache สำหรับ table list กับ schema info, Tier 2 เป็น LRU cache สำหรับ per-table details ที่ SQL completion กับ ER diagram ใช้ร่วมกัน ผลที่ได้คือ startup time ลดเหลือต่ำกว่า 100ms

ฟีเจอร์ที่โดดเด่นของ Sabiql

ฟีเจอร์ที่ไม่เคยเห็นใน TUI database tool ตัวไหนมาก่อนคือ ER diagram กด e แล้วมันเปิด diagram ใน browser ให้เลย รองรับ generate แบบ focused เฉพาะตารางที่ต้องการด้วย นอกจากนี้ยังมี Inspector Pane ที่แบ่งเป็น 7 แท็บครอบคลุมตั้งแต่ Columns, Indexes, Foreign Keys ไปจนถึง RLS policies และ auto-generated DDL ที่งัดออกมาได้เลย

แก้ไข cell in-place ก็ได้ โดยมี safety guard ป้องกัน mass-update อัตโนมัติถ้าไม่มี WHERE clause และลบ row ได้แบบ vim-style dd แล้ว :w พร้อม SQL preview ก่อน execute เสมอ

การใช้งานแบบ Vim-like และการตอบรับจากชุมชน

การใช้งานก็ vim-like ตลอด ทั้ง j/k สำหรับ scroll, g/G สำหรับ jump, f สำหรับ focus mode เต็มจอ และ Ctrl+K สำหรับ command palette config เก็บไว้ที่ ~/.config/sabiql/connections.toml รองรับ pg_service.conf ที่มีอยู่แล้วด้วย install ได้เลยผ่าน cargo install sabiql

หลังปล่อยออกมาได้รับ shout-out จาก orhun (Ratatui maintainer) ติดรายการ awesome-ratatui และ Postgres Weekly ก็หยิบไปนำเสนอ เป็นสัญญาณที่ชัดเจนว่า community กำลังรอ tool แบบนี้อยู่ครับ

Credit & Reference:

  1. I built a fast, driver-less TUI for browsing PostgreSQL, with ER diagrams
  2. riii111/sabiql — GitHub

“moss” Unix-like Kernel ที่เขียนด้วย Rust

📅 วันที่เผยแพร่: 2026-02-14

มีโปรเจคน่าสนใจมาแนะนำ moss (Linux-compatible kernel) ที่เขียนด้วย Rust และ Aarch64 assembly

การใช้ async/await ใน Kernel Context

จุดเด่นที่ทำให้ moss แตกต่างคือการใช้ async/await ใน kernel context ครับ system calls ทั้งหมดเป็น async functions ทำให้ compiler ช่วย enforce ว่าไม่สามารถ hold spinlock ขณะ sleep ได้ ซึ่งช่วยกำจัด class ของ bugs ที่เป็น deadlocks ได้ที่ต้นเหตุ แถม future ไหนก็ได้สามารถห่อด้วย .interruptable() combinator เพื่อให้ signals สามารถขัดจังหวะการรอได้อย่างถูกต้อง

ความสามารถในปัจจุบัน

ปัจจุบัน moss สามารถรัน Arch Linux aarch64 userspace ได้จริง รวมถึง bash, BusyBox, coreutils, ps, top และ strace implement ไปแล้ว 105 Linux syscalls พร้อม SMP scheduling ผ่าน EEVDF, fork/execve/clone, signal handling และ ptrace support ที่เพียงพอต่อการรัน strace บน Arch binaries

สถาปัตยกรรม libkernel ที่ทดสอบง่าย

ส่วนที่ผมชอบเป็นพิเศษคือการออกแบบ libkernel ที่แยก architecture-agnostic logic ออกมา ทำให้เทสได้บน host machine (x86) ก่อนรันบน bare metal ตอนนี้มี test suite 230+ tests เลยครับ

Roadmap ในอนาคต

โปรเจคยัง active development อยู่ roadmap มี TCP/IP stack, read/write filesystem driver, และ systemd bringup ใครสนใจ OS dev, async Rust หรืออยาก contribute (port x86, เพิ่ม syscalls, เขียน driver) แวะดูได้ครับ

Credit & Reference:

  1. moss GitHub repo

“Ironpad” เมื่อ Rust กับ AI-Assisted Development พิสูจน์ว่าพวกมันถูกสร้างมาเพื่อกันและกัน

📅 วันที่เผยแพร่: 2026-02-08

(คำเตือน…บทความนี้ยาวมาก 555) มีนักพัฒนาคนหนึ่งสร้าง full-stack project management application ชื่อ Ironpad ขึ้นมาภายในเวลาเพียง 2 วัน โดยใช้ Rust เป็น backend และพึ่งพา AI-assisted development เกือบทั้งหมด สิ่งที่ทำให้ project นี้น่าสนใจไม่ใช่แค่ความเร็วในการพัฒนา แต่คือการค้นพบว่า Rust และ AI สามารถทำงานร่วมกันได้อย่างลงตัวเหนือความคาดหมาย และที่สำคัญคือผู้พัฒนา document ทุก step ของ development process ไว้แบบ open source ทั้งหมด ทำให้เราได้เห็นภาพที่ชัดเจนว่าการพัฒนาด้วย AI ในยุคนี้เป็นอย่างไร

ทำไมถึงเลือก Rust สำหรับ Local-first App

ก่อนจะเข้าสู่เนื้อหาเชิงลึกของ development process เรามาดูกันก่อนว่าทำไมผู้พัฒนาถึงเลือก Rust แทนที่จะไปทาง Electron ซึ่งดูจะเป็นทางเลือกที่ง่ายกว่าสำหรับ desktop application Ironpad เป็น local-first, file-based project management system ที่ออกแบบมาให้ files เป็น database โดยตรง ทุก note, task, project เป็น plain Markdown files พร้อม YAML frontmatter ไม่มี cloud, ไม่มี vendor lock-in, ไม่มี proprietary formats คุณสามารถแก้ไขข้อมูลได้ทั้งใน browser UI หรือเปิดไฟล์เดียวกันนั้นใน VS Code, Obsidian, Vim หรือ text editor ใดก็ได้ที่คุณชอบ การเปลี่ยนแปลงจะ sync real-time ผ่าน WebSocket และทุกอย่างถูก version อัตโนมัติด้วย Git

การเลือก Rust นั้นเป็น deliberate choice ที่มีเหตุผลชัดเจน เมื่อเทียบกับ Electron app ที่มี bundle size 150-300 MB, ใช้ RAM 200-500 MB และใช้เวลา startup 2-5 วินาที Ironpad ที่เขียนด้วย Rust กลับได้ binary ขนาดเพียง 5 MB, ใช้ RAM แค่ 20 MB และ startup ใน sub-second (ต่ำกว่า 500ms) ความแตกต่างนี้ไม่ใช่แค่ตัวเลข แต่คือ philosophy ที่แตกต่างกันโดยสิ้นเชิง ทุกคนมี browser อยู่แล้ว ทำไมต้อง bundle อีกตัวมาด้วย? Rust backend serve API, Vue frontend รันในบราวเซอร์ที่คุณมีอยู่แล้ว double-click executable มันเปิดบราวเซอร์ให้ คุณก็เริ่มทำงานได้ทันที simple as that

สถาปัตยกรรมและ Core Design Decisions

สถาปัตยกรรมของ Ironpad ถูกออกแบบมาให้เรียบง่ายตั้งแต่แรก user launch executable จากนั้น Rust backend ที่ build ด้วย Axum 0.8 และ Tokio จะทำงานเป็น REST API server พร้อม WebSocket server สำหรับ real-time sync, file watcher ที่คอยตรวจจับการแก้ไขไฟล์จาก external editors, และ Git auto-commit system ที่ทำงานทุก 60 วินาที frontend คือ Vue 3 พร้อม Vite และ TypeScript ใช้ Milkdown (ซึ่ง based on ProseMirror) เป็น WYSIWYG markdown editor, ใช้ Pinia สำหรับ state management และท้ายสุดข้อมูลทั้งหมดคือ plain Markdown files บน disk ที่คุณสามารถแก้ไขด้วย tool ใดก็ได้

Core design decisions มีหลายจุดที่น่าสนใจมาก ประการแรกคือ files are the database ไม่มี SQLite, ไม่มี IndexedDB, file system คือ source of truth เดียว ประการที่สองคือ backend owns metadata ซึ่งหมายความว่า IDs, timestamps, และ frontmatter ถูกจัดการโดย backend อัตโนมัติ users ไม่ต้องแก้ไข metadata ด้วยตัวเอง ประการที่สามซึ่งสำคัญมากคือ external editing is a first-class citizen file watcher จะตรวจจับการเปลี่ยนแปลงจาก VS Code, Obsidian, Vim หรือ editor อื่นๆ และ sync ไปยัง browser UI แบบ real-time ผ่าน WebSocket และสุดท้ายคือ Git for everything auto-commit ทุก 60 วินาที, manual commit พร้อม custom messages ได้, และมี full diff viewer built-in ใน UI

API surface มีทั้งหมด 29 endpoints ครอบคลุม Notes, Projects, Tasks ทั้งแบบ per-project และ cross-project, Daily notes, Assets (upload และ serve), Search, Git operations และ WebSocket endpoint สำหรับ real-time file change notifications สถาปัตยกรรมนี้เรียบง่ายแต่ครอบคลุมทุกสิ่งที่ต้องการสำหรับ productivity application แบบ local-first

AI-Assisted Development ด้วย “Open Method”

นี่คือจุดที่ project นี้เริ่มน่าสนใจจริงๆ Ironpad ถูกสร้างขึ้นมาด้วย AI-assisted development ทั้งหมด ไม่ใช่แค่ autocomplete แต่คือทุกอย่าง ตั้งแต่ architecture, PRD, implementation, debugging ทั้งหมด ผู้พัฒนาเรียกแนวทางนี้ว่า “Open Method” (ไว้มีโอกาสผมจะมาเล่าให้ฟัง น่าสนใจมากครับในยุคนี้) ไม่ใช่แค่ open source code แต่เป็น open development process ทั้งหมดถูก document ไว้ใน repo ภายใต้ docs/ai-workflow/ ให้ทุกคนได้เรียนรู้

Workflow แบ่งออกเป็น 6 phases ที่แต่ละ phase มีความสำคัญแตกต่างกัน

  • Phase 1 คือ Multi-AI Consultation ก่อนจะเขียนโค้ดสักบรรทัด ผู้พัฒนาคุยกับ AI models หลายตัว ใช้ Claude สำหรับ architecture, Perplexity สำหรับ library research, Gemini สำหรับ second opinions
  • Phase 2 คือ PRD Creation และนี่คือ single highest-leverage activity ของทั้ง project พวกเขาเขียน detailed Product Requirements Document ครอบคลุมทุกอย่าง features, API design, data models, edge cases
  • Phase 3 คือ Task Decomposition แบบง่ายๆ เพื่อทดสอบว่า AI สามารถ handle ได้มากแค่ไหนในครั้งเดียว
  • Phase 4 คือ Context Loading ผู้พัฒนาจึงใช้ Context7 (MCP tool) เพื่อ pull current documentation พร้อมกับสร้าง ai-context.md
  • Phase 5 คือ Implementation ที่ build features ใน focused sessions, test, update checklist แล้ว repeat
  • Phase 6 คือ Verification ซึ่งเป็นหลักการสำคัญ AI เขียนโค้ด แต่คุณต้อง verify product เอง รันมัน, ลอง edge cases

Tools ที่ใช้ใน development ประกอบด้วย Cursor IDE, Claude Opus 4.5/4.6, Perplexity AI, Google Gemini และ Context7 (MCP)

ความเปลี่ยนแปลงเมื่อ AI Context ขยายเป็น 1M Tokens

กลางๆ development มีเหตุการณ์สำคัญเกิดขึ้นที่เปลี่ยน workflow ของ project ไปโดยสิ้นเชิง Claude’s context window เพิ่มจาก 200K เป็น 1M tokens การใช้ Claude 4.5 200K ต้องแบ่ง features ยิบย่อย แต่เมื่อเปลี่ยนมาใช้ Claude Opus 4.6 กับ 1M tokens ทุกอย่างเปลี่ยนไป codebase ทั้งหมด 80+ files พอดีใน context เดียว สามารถ implement full features ใน single sessions ได้เลย

การ demonstrate ที่ชัดเจนที่สุดคือ codebase audit ผู้พัฒนาโหลด Ironpad codebase ทั้งหมดแล้วถาม “what’s wrong?” AI หาเจอ 16 issues รวมถึง bug ที่สำคัญหลายตัว 14 จาก 16 issues ถูกแก้ไขใน single session การทำ comprehensive audit แบบนี้เป็นไปไม่ได้เลยตอนที่มีแค่ 200K tokens

ทำไม Rust ถึงคู่ควรกับ AI Development?

จากประสบการณ์ตรงของ project นี้ เราได้เห็นภาพที่ชัดเจนว่าทำไม Rust จึงเหมาะกับ AI-assisted development มากเป็นพิเศษ

  1. Rust’s strict compiler: ผู้พัฒนาระบุชัดเจนว่า “Rust is excellent for AI-assisted development because the compiler catches entire categories of bugs before runtime” compiler ทำหน้าที่เป็น safety net ที่แข็งแกร่งสำหรับโค้ดที่ AI generate ขึ้นมา
  2. Type system ของ Rust: ช่วย AI ในการทำความเข้าใจ intent ด้วย ownership และ borrowing rules AI สามารถ reason เกี่ยวกับ data flow ได้ชัดเจน
  3. Ecosystem maturity: Rust มี crates คุณภาพสูงที่พร้อมใช้งาน project นี้ใช้ Axum 0.8, Tokio, git2, ripgrep การมี crates เหล่านี้หมายความว่า AI ไม่ต้องเขียน low-level code เอง
  4. Error messages ที่ดีเยี่ยม: เมื่อ AI generate code ที่ผิด compiler ไม่ได้แค่บอกว่าผิด แต่บอกว่าผิดอย่างไร ทำไมผิด และควรแก้ไขอย่างไร ช่วย Feedback loop ให้การแก้ไขไวขึ้น

บทเรียนจาก Project: Patterns for AI Coding

จากการ document อย่างละเอียด เราได้เห็น patterns ที่ work และไม่ work ชัดเจน

สิ่งที่ work well: PRD-first development คือ highest-leverage activity การใช้ ai-context.md pattern เพื่อเก็บ architecture rules สำหรับ codebase การเริ่ม fresh chats over long conversations เพื่อป้องกัน context noises

สิ่งที่ไม่ work: การ trusting “this should work” จาก AI วิธีแก้คือต้อง Test everything การใช้ requirements กว้างๆ (เช่น “Add search” สู้ระบุเจาะจงไม่ได้) และเรื่อง over-engineering ที่ AI มักเพิ่มสิ่งที่เผื่ออนาคตวิธีแก้คือต้องคอยย้ำ YAGNI (You Aren’t Gonna Need It) เสมอ

บทสรุปของ Ironpad

Ironpad มี feature set ที่ครบถ้วนสำหรับ project management application เครื่องมือสุดแรงเร็วในขนาด binary 5 MB ใช้ RAM 20 MB และ startup time sub-second บทเรียนสำคัญคือ AI-assisted development is here to stay มันต้องกระทำควบคู่กับ process, verification และ human judgment AI เป็นตัวขยายพลังของนักพัฒนา โดยเฉพาะฝั่ง Rust ที่ตัว Compiler เป็นเพื่อนซี้ช่วยคัดกรองคุณภาพ Code

สำหรับใครที่สนใจสามารถลองเล่น Ironpad ได้ที่ GitHub repo เลยครับ แล้วชุมชนเรามีใครใช้ AI Assisted ในการพัฒนา Rust บ้างไหม แชร์คุยกันได้เลย!

Credit & Reference:

  1. I Built a Full Project Management App in 2 days Using Claude 4.6
  2. ironPad GitHub repo

“Redistill” บทพิสูจน์ศักยภาพของ Rust ในการทลายขีดจำกัด Throughput ของ Redis สู่ระดับ 9 ล้าน Ops/sec

📅 วันที่เผยแพร่: 2026-02-05

บทนำ (Introduction)

“เราจะสร้าง Key-Value Store ที่เร็วกว่า Redis ได้จริงหรือ?” เป็นคำถามที่ท้าทายมาก แม้ Redis จะครองบัลลังก์ด้วยความเร็วและความเสถียร แต่นั่นอยู่บนพื้นฐานของสถาปัตยกรรมยุค Memory-first แบบดั้งเดิมที่เป็น Single-threaded ซึ่งกลายเป็นคอขวดสำคัญในยุคของ Modern CPU ที่มี Core มหาศาล

ล่าสุดโปรเจกต์ Redistill ได้ถือกำเนิดขึ้นด้วยปรัชญาการออกแบบที่น่าสนใจผ่านภาษา Rust โดยไม่ได้แค่พยายามทำเหมือนแต่เลือกที่จะ “กลั่น” (Distill) เอาเฉพาะแก่นแท้เพื่อรีดประสิทธิภาพสูงสุด จนสามารถทำ Benchmark ชนะทั้ง Redis และผู้ท้าชิงรุ่นใหม่อย่าง Dragonfly ได้อย่างขาดลอย

ทำไมต้อง Rust? (Why Rust?)

หัวใจสำคัญที่ทำให้ Redistill แตกต่างจาก KV Store ทั่วไป ไม่ใช่แค่การเขียนใหม่ด้วย Rust แต่คือการตัดสินใจทางสถาปัตยกรรมที่เฉียบคม ผนวกกับความสามารถในการจัดการ Memory Safety ที่ยอดเยี่ยม

Safe Concurrency & Lock-free Reads

การตัดส่วนเกินที่ไม่จำเป็นออก ทำให้ Redistill ลด Instruction Footprint ลงได้มาก ผนวกกับ Ownership Model ของ Rust ทำให้สามารถสร้างสถาปัตยกรรมแบบ Multi-threaded with Lock-free Reads ได้อย่างสมบูรณ์แบบ แตกต่างจาก Redis เดิมที่ติดข้อจำกัดกระบวนทัศน์ Single-thread หรือ Dragonfly (C++) ที่ต้องใช้ Shared-nothing architecture ที่ซับซ้อนกว่าเพื่อเลี่ยง Race condition แต่ Rust อนุญาตให้ Redistill กระจาย Load ไปยังทุก Core ได้อย่างปลอดภัยและเต็มประสิทธิภาพโดยมี Overhead จากการ Context Switch ที่ต่ำมาก

สถาปัตยกรรมและการออกแบบ (Architecture & Design)

ผู้พัฒนาได้วิเคราะห์การใช้งานจริงและพบว่า 90% ของคำสั่งที่ใช้งานกันอย่างหนักหน่วงมีเพียงแค่ Strings และ Hashes การตัดส่วนเกินที่ไม่จำเป็นออก ทำให้ Redistill สามารถ Optimize Code Path ได้สั้นที่สุด

ในมิติของการใช้งาน Redistill ยังคงรักษาความเข้ากันได้กับ RESP Protocol (Redis Serialization Protocol) ไว้อย่างสมบูรณ์ ซึ่งเป็นกลยุทธ์แบบ Drop-in Replacement ที่ชาญฉลาด เราสามารถใช้ Client Library เดิมอย่าง ioredis ใน Node.js หรือ redis-py ใน Python เชื่อมต่อเข้ามาได้ทันทีโดยไม่ต้องแก้โค้ดฝั่ง Application

ภายใน Redistill ใช้เทคนิคการ Parse ข้อมูลเครือข่ายที่มีประสิทธิภาพสูง (คาดการณ์ว่าเป็น Zero-copy parsing ตามสไตล์ Rust) ทำให้ได้ Bandwidth สูงถึง 1.58 GB/s รองรับ Use Case ที่ต้องการความเร็วระดับ Extreme เช่น Session Storage, Real-time Leaderboard หรือ API Response Caching ที่ต้องการ Cache Hit Rate สูงและ Eviction Policy ที่แม่นยำ

Feature Highlights & Performance

ผลลัพธ์จากการ Benchmark บนเครื่องระดับ Production-grade อย่าง AWS c7i.16xlarge (Intel 64 cores, 128GB RAM) ด้วย memtier_benchmark ได้สร้างตัวเลขที่สั่นสะเทือนวงการ:

Throughput & Latency Distribution

  • Throughput: สูงถึง 9.07 ล้าน Operations ต่อวินาที ซึ่งเร็วกว่า Redis ถึง 4.5 เท่า และเร็วกว่า Dragonfly ถึง 1.7 เท่า
  • p50 Latency: ทำได้ต่ำเพียง 0.479ms (เทียบกับ Redis 2.383ms)
  • p99.9 Latency: รักษาความเสถียรไว้ที่ 1.59ms แสดงให้เห็นว่า Rust Runtime และการจัดการ Allocator ภายใน สามารถรับมือกับ Spike Load ได้ดีเยี่ยมโดยไม่มีอาการ GC Pause หรือ Latency Jitter มารบกวน

บทเรียนและทิศทางของโปรเจกต์ในอนาคต

ในฐานะโปรเจกต์ที่เพิ่งมีอายุเพียง 8 สัปดาห์ และพัฒนาขึ้นเพื่อแก้ Pain Point เฉพาะจุด Redistill จึงมาพร้อมกับ Trade-off ที่ชัดเจน คือ การตัดฟีเจอร์ที่ไม่จำเป็นออกเพื่อแลกกับความเร็วสูงสุด

  • ปัจจุบันยังรองรับเพียง Strings และ Hashes เป็นหลัก
  • ยังไม่มี Clustering Mode (เน้น Single-instance Vertical Scaling)
  • แม้จะมีระบบ Persistence แบบ Snapshot (สำหรับการทำ Warm Restart) แต่โดย Default จะถูกปิดไว้เพื่อให้ Memory Operation ทำงานได้เต็มสูบที่สุด

บทสรุป (Conclusion)

ผมมองว่า Redistill คือ Use Case Study ชั้นดีที่แสดงให้เห็นว่า Rust ไม่ได้เป็นเพียงภาษาที่ขายความปลอดภัย (Safety) แต่เป็นเครื่องมือที่ทรงพลังที่สุดในยุคปัจจุบันสำหรับการทำ System Programming ที่ต้องการรีดประสิทธิภาพของ Hardware ออกมาทุกหยด

การที่ Developer เพียงคนเดียวสามารถสร้าง Database Engine ที่ Outperform โปรเจกต์ระดับโลกได้ในระยะเวลาอันสั้น คือเครื่องยืนยันว่า Rust Ecosystem และ Concurrency Model คืออนาคตของการสร้าง High-Throughput Systems อย่างแท้จริง

Credit & Reference:

  1. Redistill GitHub repo

“Feste” เมื่อ Rustacean สร้าง GPT-2 จากศูนย์ ไร้ PyTorch มีแค่ Math และ Memory Layout

📅 วันที่เผยแพร่: 2026-02-03

การทำ Machine Learning เรามักคุ้นเคยกับการมอง Tensor เป็นกล่องดำที่ PyTorch จัดการให้ แต่การจะเข้าใจ LLM อย่างถ่องแท้ บางครั้งเราต้องกล้าที่จะทิ้ง abstraction เหล่านั้น แล้วลงมือเขียนมันขึ้นมาเองด้วย Rust ตั้งแต่บรรทัดแรก (ใครพร้อมก็ตามมาครับ) โปรเจกต์ “Feste” คือตัวอย่างโปรเจกต์ที่จะพาเราเรียนรู้ตั้งแต่การแปลง Text เป็น Byte ไปจนถึงการเขียน Manual Backpropagation เพื่อเทรนโมเดลให้พูดภาษาเชกสเปียร์ได้

Tokenization ด้วย Byte Pair Encoding (BPE)

มาเริ่มกันที่ Tokenization ปัญหาคลาสสิกของ LLM คือโมเดลไม่ได้อ่าน “ตัวหนังสือ” แบบที่เราอ่าน แต่มันเห็นเป็น token ID การเลือกใช้ Byte Pair Encoding (BPE) แบบ GPT-2 นั้นฉลาดมาก เพราะมันทำงานในระดับ Byte (UTF-8) ทำให้เราจัดการกับ Unicode ภาษาแปลกๆ หรือ Emoji ได้โดยไม่ต้องมี Vocabulary มหาศาล

ความท้าทายทางเทคนิคของ BPE คือขั้นตอนการ Training ที่ต้องนับความถี่ของคู่ Byte ที่ติดกัน (Adjacent pairs) ซ้ำแล้วซ้ำเล่าใน Corpus ขนาดใหญ่ ตรงนี้เองที่ Rust เฉิดฉาย แทนที่จะรอ Python วนลูป เราใช้ Rayon เข้ามาจัดการ Parallelism:

  • กระจายงานนับคู่ Byte ไปยังทุก Core ของ CPU ด้วย par_chunks
  • ใช้ fold/reduce เพื่อรวมผลลัพธ์จาก HashMap ย่อยๆ
  • ทำให้การเทรน Tokenizer ที่ซับซ้อนเสร็จในหลักวินาที โดยที่เรายังคงความถูกต้องของการจัดการ Boundary ระหว่าง chunk ได้อย่างแม่นยำ

Tensor Operations และ Memory Layout

เมื่อได้ตัวเลขมาแล้ว เราก็เข้าสู่หัวใจสำคัญนั่นคือ Tensor Operations แทนที่จะใช้ Library สำเร็จรูป เราเลือกสร้าง struct Tensor ขึ้นมาเองโดยเก็บข้อมูลดิบเป็น Vec<f32> แบบ Flat Array ก้อนเดียว เพื่อให้ Memory Contiguous ที่สุด

  • ใช้ shape กับ strides เป็นตัวกำหนด View ในการเข้าถึงข้อมูล
  • เทคนิคนี้ทำให้ operations อย่าง reshape หรือ transpose แทบจะไม่มี cost เพราะเราแค่เปลี่ยนตัวเลข stride โดยไม่ต้องย้ายข้อมูลจริงใน Memory

แต่ความมันส์ที่แท้จริงอยู่ที่ Matrix Multiplication ซึ่งเป็นคอขวดของ Deep Learning การเขียน Loop 3 ชั้นแบบ Naive (for i, j, k) นั้นฆ่า Performance บน Modern CPU เพราะมันทำลาย Cache Locality อย่างยับเยิน

การรีด Performance (Cache Blocking & Auto-vectorization)

ทางออกของเราคือการทำ Cache Blocking หรือ Tiling โดยแบ่ง Matrix ออกเป็น Block ย่อยขนาด 8x8 เพื่อให้ข้อมูลฟิตพอดีใน L1 Cache แต่จุดที่ Rust แสดงพลังขั้นสุดคือตอนที่เรา Optimize Inner Loop ครับ:

  • ตอนแรกที่ใช้ Indexing แบบ C-style (a[i * n + k]) คอมไพเลอร์ไม่สามารถ Optimize ได้ดีนัก
  • แต่พอเปลี่ยนมาใช้ Iterator Pattern (iter().zip()) ของ Rust ตัว LLVM Backend ฉลาดพอที่จะเห็น Pattern การเข้าถึงข้อมูลที่ต่อเนื่อง และทำการ Auto-vectorization สร้างคำสั่ง SIMD (AVX2/NEON) ให้เราอัตโนมัติ โดยไม่ต้องเขียน Assembly เอง

Model Architecture สะท้อน GPT-2

เมื่อรากฐานคณิตศาสตร์แน่นปึก เราก็ประกอบร่างเป็น Model Architecture โค้ด Rust สะท้อนโครงสร้างของ GPT-2 ออกมาอย่างชัดเจน:

  • ข้อมูลไหลผ่าน Embedding Layers (ที่บวก Positional Encoding เข้าไปตรงๆ)
  • วิ่งผ่าน Transformer Block 12 ชั้น และจบที่ Layer Norm
  • ตัว Multi-Head Attention ถูก implement โดยการแตก Tensor 768 dimensions ออกเป็น 12 heads (64 dims) แล้วคำนวณ Attention Score พร้อมกัน

สิ่งที่น่าสนใจคือการจัดการ Causal Masking ด้วยเทคนิค masked_fill โดยใช้ค่า -infinity แทนที่ตำแหน่งในอนาคตก่อนเข้า Softmax เพื่อรับประกันว่าโมเดลจะไม่ “แอบดูเฉลย” (Peeking) นอกจากนี้เรายังใช้ GELU เป็น Activation Function แทน ReLU เพื่อให้ Gradient ไหลได้นุ่มนวลกว่าในช่วงค่าติดลบ ซึ่งสำคัญต่อการ Convergence

Manual Backpropagation ตั้งแต่ศูนย์

ส่วนที่ยากที่สุดคือ Training Infrastructure เราไม่ได้ใช้ Autograd Engine แต่เราเขียน Manual Backpropagation เองทั้งหมดตาม Chain Rule ของ Calculus:

  • เข้าใจการไหลของ Gradient ย้อนผ่าน Softmax, Attention Heads และ Residual Connections
  • Implement AdamW Optimizer โดยแยก Weight Decay ออกจาก Gradient Update ตามสูตรที่ถูกต้อง (ซึ่งต่างจาก Adam ปกติ)
  • ใช้ Gradient Clipping เพื่อป้องกันปัญหา Exploding Gradients
  • ทั้งหมดทำงานอยู่บน Memory Safety Model ของ Rust ที่การันตีว่าเราจะไม่เผลอเขียนทับ Gradient หรือ Access Tensor ผิด Shape ระหว่างการคำนวณที่ซับซ้อนนี้

บทสรุป

ผลลัพธ์คือ Feste โมเดลที่เทรนบน CPU เพียวๆ แต่สามารถเรียนรู้ที่จะพูดภาษาเชกสเปียร์ได้จริง กราฟ Loss ลดลงอย่างสวยงาม และ Text Generation เริ่มจับโครงสร้างประโยคและคำศัพท์โบราณได้

การเขียน LLM ด้วย Rust ครั้งนี้พิสูจน์ให้เห็นว่า เมื่อเราเข้าใจ Low-level operations และใช้เครื่องมือที่ถูกต้อง เราสามารถรีดประสิทธิภาพและควบคุมทุก Byte ของ Memory ได้ดั่งใจ โดยไม่ต้องพึ่งพา Magic ของ Framework ใดๆ

Credit & Reference:

  1. feste GitHub repo

Rust Research

ยังไม่มีบทความในหมวดหมู่นี้

Rust Tools

git-ai เครื่องมือที่เอาไว้ Track AI Code

📅 วันที่เผยแพร่: 2026-03-02

Open Source ชื่อ git-ai ไอเดียคือน่าสนใจมาก เขาทำเครื่องมือ track ว่าโค้ดส่วนไหน AI เขียน ส่วนไหนคนเขียน 555 โดยโจทย์ยากคือต้องเข้าไปยุ่งกับระบบลึกๆ ของ Git (Git Internals) ซึ่งเสี่ยงพังง่ายมาก แต่โปรเจกต์นี้ใช้จุดเด่นของ Rust อย่าง Enum และ Pattern Matching มาจัดการ Logic ที่ซับซ้อน อย่างในฟังก์ชัน execute_diff ทำให้การคำนวณความเปลี่ยนแปลงของไฟล์ในแต่ละ Commit ปลอดภัยและแม่นยำ อ่านโค้ดแล้วเข้าใจง่ายว่ากำลังจัดการ State ไหนอยู่ ลดโอกาสเกิด Bug เวลาดึงประวัติไฟล์

การจัดการข้อมูลด้วย Git Notes และ Struct

ในส่วนของการเก็บข้อมูลก็น่าสนใจครับ เขาเลือกใช้ Git Notes เพื่อแปะข้อมูลว่า “ใครเขียนบรรทัดไหน” แนบไปกับ Commit โดยไม่ต้องไปแก้ Commit Hash เดิม ซึ่งในมุมมองของ Rust Developer การจัดการข้อมูลที่ซับซ้อนแบบนี้ เขาใช้ Struct มากำหนดโครงสร้างข้อมูลให้ชัดเจน เวลาอ่านหรือเขียนข้อมูลลงไฟล์ (Serialization) ระบบ Type System ของ Rust จะช่วยเช็คให้มั่นใจว่าหน้าตาข้อมูลถูกต้องเสมอ ไม่ต้องกลัวว่าข้อมูลจะแหว่งหรือ Type ผิดเวลาดึงข้อมูลข้ามเครื่องผ่าน git fetch ครับ

ประสิทธิภาพแบบ Local-first และ Background Processing

เรื่องประสิทธิภาพก็เป็นจุดที่มือใหม่น่าศึกษาครับ ปกติถ้าเราใส่ Logic ใน Git Hook เยอะๆ เวลาพิมพ์ git commit มันจะหน่วง แต่ตัวนี้เขาออกแบบเป็น Local-first คือบันทึกข้อมูลลงเครื่องเราก่อน แล้วค่อยแยก Process อีกตัวไปทำงานเบื้องหลัง (Background Process) เพื่อส่งข้อมูลหรือประมวลผลทีหลัง ทำให้การ Commit ลื่นไหลเหมือนเดิม ไม่ต้องรอ Network ซึ่งการแตก Process และจัดการ Memory แบบนี้ Rust ทำได้กระชับและจัดการทรัพยากรได้ดีมากครับ

ความสะดวกในการใช้งานแบบ Single Binary

ความสะดวกในการเอาไปใช้ พอ Compile ออกมาเป็น Single Binary ก้อนเดียว มันเลยเอาไปวางแล้วรันได้เลย ไม่ต้องลง Runtime อะไรเพิ่มให้วุ่นวาย รองรับทั้ง Windows, Mac, Linux (WSL) ใครที่อยากเห็นตัวอย่างการเขียน CLI Tools ที่เป็นระเบียบและจัดการเรื่อง System ได้ดี ลองเข้าไปแกะโค้ด git-ai ดูครับ เป็นแหล่งเรียนรู้ชั้นดีเลยทีเดียว

Credit & Reference:

  1. git-ai GitHub repo
  2. git-ai Website
  3. git-ai Docs

Rust Update

จาก Feature สู่ Foundation

📅 วันที่เผยแพร่: 2026-02-12

ในเดือนมกราคม 2026 ที่ผ่านมาทิศทางของ Rust ได้ขยับจากการตั้งเป้าหมายรายฟีเจอร์ไปสู่สิ่งที่เรียกว่า “Roadmaps” และ “Application Areas” อย่างเต็มตัว โดยเน้นการแก้ปัญหาระดับโครงสร้างที่ต้องใช้เวลาพัฒนาข้ามปี (Multi-year implementation) ซึ่งความน่าสนใจในปีนี้ไม่ได้อยู่ที่ Syntax ใหม่ๆ แต่อยู่ที่การลงลึกไปใน Low-level Integration กับระบบยักษ์ใหญ่ที่มีอยู่เดิมอย่าง Linux Kernel และ CPython

ระดับ System Integration: Linux Kernel และ CPython

ในฝั่งของ Rust for Linux เรากำลังก้าวข้ามเฟสของการเขียน Driver เบื้องต้น ไปสู่การแก้ปัญหาที่ระดับ Language Semantics เพื่อให้สอดคล้องกับ Kernel Model โดยตรง ทีมงานกำลังโฟกัสเรื่อง Field Projections และ In-place Initialization ซึ่งเป็นหัวใจสำคัญของการจัดการ Memory ที่ปลอดภัยในสภาวะที่ struct ถูก Pin อยู่ นอกจากนี้ยังมีการผลักดันฟีเจอร์ Supertrait auto impl เพื่อลด Boilerplate code จำนวนมหาศาล และ RFC#3848 ที่อนุญาตให้ส่ง pointer ไปยัง const ใน assembly block ได้ ซึ่งจำเป็นมากสำหรับงาน Low-level ASM ที่ต้องการความถูกต้องแม่นยำสูง

ความท้าทายในระดับ System Integration ยังขยายวงไปถึงโปรเจกต์ CPython ซึ่งทีม Compiler และ Libs-API กำลังทำงานร่วมกับฝั่ง Python อย่างใกล้ชิดเพื่อพิจารณานำ Rust เข้าไปเป็นส่วนหนึ่งของ Interpreter แต่โจทย์ทางเทคนิคนั้นซับซ้อนกว่าที่คิด ตั้งแต่ปัญหา Bootstrapping Cycle (เพราะปัจจุบัน Rust ใช้ Python script ในการ build ตัวเอง หาก Python มา depend บน Rust จะเกิดวงจรไก่กับไข่), การจัดการ Symbol Visibility เมื่อต้อง Link Rust std lib เข้ากับ Python extension modules, ไปจนถึงการจูน Linker Arguments ที่แตกต่างกันระหว่าง bin และ lib targets ใน Crate เดียวกัน รวมถึงการออกแบบ Interop ระหว่าง async Rust กับ asyncio ของ Python ให้ทำงานร่วมกันได้โดยไม่เกิด Overhead

Developer Experience และ cargo-script

ในส่วนของ Developer Experience ฟีเจอร์ที่หลายคนรอคอยอย่าง cargo-script ได้เข้าสู่ช่วง Final Comment Period (FCP) แล้ว การเปลี่ยนแปลงนี้จะทำให้เราสามารถรันไฟล์ .rs เดี่ยวๆ ที่ระบุ Dependency ในรูปแบบ Front matter (subset ของ Cargo.toml) ได้ทันที โดยเบื้องหลังความสำเร็จนี้ ทีม Lang ได้แก้ปัญหาทางเทคนิคเล็กๆ แต่สำคัญ อย่างการจัดการตัวอักษร Stray Carriage-Return (\r) ใน source code ซึ่งเคยเป็น blocker ที่ทำให้ tooling ตีความ new line ผิดพลาด ตอนนี้ทุกอย่างได้รับการแก้ไขและพร้อมสำหรับการใช้งานจริงแทน Shell script ที่ซับซ้อน

ความปลอดภัยของ Supply Chain

ในเรื่องความปลอดภัยของ Supply Chain ในระดับ Enterprise ทีมงานกำลังวางโครงสร้างระบบ Mirroring & Verification ใหม่บนพื้นฐานของ TUF (The Update Framework) เพื่อให้มั่นใจว่า Crate ที่ถูกดึงผ่าน Mirror Server ขององค์กรหรือ Linux Distro ต่างๆ นั้น เป็นไบนารีเดียวกับต้นฉบับจาก Crates.io 100% โดยไม่มีการปลอมแปลงระหว่างทาง เป็นการปิดช่องโหว่ความปลอดภัยในระดับ Infrastructure ให้แน่นหนายิ่งขึ้น

เพิ่มเติม: cargo-script เจ๋งยังไง?

เผื่อใครสงสัยเกี่ยวกับ cargo-script ว่ามันเจ๋งยังไง

แต่เดิมถ้าอยากเทส library ตัวนึง หรือเขียน script สั้นๆ สิ่งที่เราจะต้องทำคือ cargo new my-temp-project (สร้าง folder structure) จากนั้นเข้าไปแก้ Cargo.toml เพื่อเพิ่ม dependency เพิ่มแล้วก็เข้าไปเขียนโค้ดใน src/main.rs และสั่ง cargo run

แต่ด้วย cargo-script เราสามารถสร้างไฟล์ .rs แค่ไฟล์เดียว แล้วรันได้เลย (เช่น cargo ./hello-world.rs) โดยไม่ต้องมี folder src หรือไฟล์ Cargo.toml แยก นอกจากนี้ทีเด็ดคือ “Front Matter” สิ่งที่ทำให้ cargo-script ต่างจากการเขียน script ทั่วไปคือ มันอนุญาตให้เราฝัง config ของ Cargo.toml ลงไปในส่วนหัวของไฟล์ .rs ได้เลย (Embedded Manifest) ตามโค้ดที่เป็นรูปภาพประกอบครับ

Credit & Reference:

  1. Inside Rust Blog - Program management update (January 2026)

Rust Project Goals 2026 วิวัฒนาการครั้งสำคัญของกระบวนการพัฒนาที่ Rustacean ควรรู้

📅 วันที่เผยแพร่: 2026-02-07

เมื่อวันที่ 3 กุมภาพันธ์ 2026 ที่ผ่านมา Niko Matsakis ในนาม Goals team ได้เผยแพร่ข้อมูลสำคัญผ่าน Inside Rust Blog ที่ถือเป็นจุดเปลี่ยนครั้งสำคัญของวิธีการวางแผนและพัฒนา Rust Project นั่นคือการเปิดตัว draft แรกของ Rust Project Goals RFC สำหรับปี 2026 ซึ่งไม่ใช่แค่เอกสารวางแผนธรรมดา แต่เป็นการปรับเปลี่ยนกระบวนทัศน์ทั้งหมดของวิธีที่ Rust community ทำงานร่วมกันในระดับ ecosystem

จากรอบหกเดือนสู่รอบปี

การเปลี่ยนแปลงครั้งนี้เริ่มต้นจากการตระหนักรู้ที่สำคัญว่า Goals ส่วนใหญ่ของ Rust ไม่ใช่สิ่งที่จะสำเร็จได้ภายในหกเดือน Rust Project จึงเปลี่ยนจากการวางแผนทุกหกเดือน (H1/H2) มาเป็นรอบปีเดียว โดย Goals program นี้มุ่งเน้นไปที่งานขนาดใหญ่ระยะยาวที่ต้องการความทุ่มเทอย่างต่อเนื่องตลอดทั้งปี แน่นอนว่าสมาชิกทีมยังสามารถเพิ่ม goals ใหม่ได้ในภายหลัง แต่ต้องมี champion พร้อมแล้ว และได้รับความเห็นชอบจากทีมว่านี่คือสิ่งที่พวกเขาต้องการสนับสนุนจริงๆ นี่คือการปรับตัวเพื่อรองรับความซับซ้อนที่เพิ่มขึ้นของโปรเจกต์และความต้องการที่หลากหลายจาก community

Flagship Themes: ภาพรวมสำหรับทุกคน

สิ่งที่น่าสนใจอย่างยิ่งคือแนวคิดของ “Flagship Themes” ที่ถูกออกแบบมาเพื่อให้คนที่ไม่ได้ติดตาม Rust อย่างใกล้ชิดทุกวันสามารถเข้าใจภาพรวมของสิ่งใหญ่ ๆ ที่กำลังจะเกิดขึ้นได้ Themes เหล่านี้ไม่ได้จำกัดอยู่แค่ภายในปีเดียว แต่หลาย ๆ themes เป็น multi-year technical programs เช่น “Beyond the &” ซึ่งแสดงให้เห็นถึงความมุ่งมั่นในการแก้ไขและพัฒนาระบบพื้นฐานของภาษาอย่างต่อเนื่อง Flagship themes ชุดปัจจุบันถูกคัดเลือกมาจากการอ่านและวิเคราะห์ goals ต่างๆ แล้วมองหาแนวโน้มที่ชัดเจน แต่วิสัยทัศน์ในอนาคตคือทุก flagship theme จะมี point of contact ที่รับผิดชอบในการถือวิสัยทัศน์ รับคำถาม และช่วยร่าง blog posts เป็นระยะเพื่ออัพเดทความคืบหน้าโดยรวม

ซึ่งถ้าคุณสนใจเสนอ flagship theme ใหม่ ยังทำได้จนถึงวันที่ 14 กุมภาพันธ์ (วันวาเลนไทน์) โดยเปิด PR ผ่าน FLAGSHIP_TEMPLATE.md หรือหากต้องการเสนอการเปลี่ยนแปลง theme ที่มีอยู่ หรือสนใจเป็น point-of-contact สามารถติดต่อได้ที่ project-goals/2026-workshop

Team Ask Levels: จัดการ Bandwidth อย่างมีประสิทธิภาพ

หัวใจสำคัญของระบบนี้อยู่ที่การจัดการ bandwidth ของทีมอย่างมีประสิทธิภาพผ่าน Team Ask levels ที่ถูกแบ่งเป็น Small, Medium และ Large อย่างชัดเจน เพื่อป้องกันปัญหา overcommitment ที่มักเกิดขึ้นในโปรเจกต์ open source ขนาดใหญ่

  • Small Ask: เหมาะสำหรับงานที่ต้องการ routine reviews และ actions เล็กๆ น้อยๆ โดยทั่วไปคืองานที่ใช้แค่ PR เดียว เช่น การเพิ่ม lint ใหม่ ซึ่งทั้ง Lang team และ Compiler team จะถือว่าเป็น small ask เหมือนกัน
  • Medium Ask: เหมาะสำหรับการสำรวจ design หรือ feature ด้วยการสนับสนุนแบบ dedicated จากสมาชิกทีม โดยทีมที่เหลือจะเข้ามาช่วยในระดับ vibe-check และงานเล็กๆ ตัวอย่างเช่น การ drive early stage language experiment จะเป็น medium ask ทั้งสำหรับ Lang และ Compiler teams หรืองานที่ซับซ้อนของ compiler ที่ต้องการหลาย PRs ก็จะเป็น medium ask สำหรับ Compiler team
  • Large Ask: นั้นใช้สำหรับงานที่ต้องการ consensus ภายในทีมเกี่ยวกับ design หรือ feature เช่น RFCs, stabilizations หรืองานอื่นๆ ที่ต้องการความเห็นพ้องจากทั้งทีม

ตัวอย่างที่ชัดเจนคือการ stabilize language feature ซึ่งเป็น large ask สำหรับ Lang team แต่กลับเป็นแค่ medium ask สำหรับ Compiler team หรืองานระดับ “vet and stabilize subtle reference changes” และ “overhaul compiler’s incremental system” ที่เป็น large asks ที่ต้องใช้ทรัพยากรมหาศาล

ระบบ levels เหล่านี้ถูกออกแบบมาเพื่อช่วยหลีกเลี่ยงการ overcommit โดยมีหลักการว่าทีมควรรับ large items เพียงจำนวนน้อย อาจเป็นศูนย์เลยก็ได้ ขึ้นอยู่กับ bandwidth ที่มี และแต่ละคนไม่ควร champion goals มากเกินไปเช่นกัน นอกจากนี้ยังมีระดับ “Vibes” อีกด้วย ซึ่งเป็นการ quick check ว่าไอเดียของคุณคุ้มค่าที่จะสำรวจต่อและนำเวอร์ชันที่ mature กว่ามาให้ทีมในอนาคตหรือไม่ แนวคิดนี้ช่วยให้การทดลองและ innovation เกิดขึ้นได้โดยไม่ต้อง commit ทรัพยากรมากเกินไปตั้งแต่เริ่มต้น

ระบบ Team Champion

การสนับสนนนี้มาพร้อมกับระบบ Team Champion ที่ถูกออกแบบมาอย่างพิถีพิถัน Team Champion คือคนที่ตกลงจะสนับสนุน goal owner ในระดับบุคคล โดยคาดหวังว่าจะพบกับ goal owner แบบ weekly หรือ biweekly Champions มักช่วยให้คำแนะนำด้าน design และแนะนำว่าควรพูดคุยกับใครในทีมเพื่อขอข้อมูลเพิ่มเติม พวกเขาควรพร้อมที่จะตอบคำถามจากสมาชิกคนอื่นๆ ในทีมเกี่ยวกับ goal นั้นๆ ด้วย ที่น่าสนใจคือถ้าคุณเป็นสมาชิกของทีมนั้น คุณสามารถ champion goal ของตัวเองได้ ระบบนี้แก้ปัญหาสำคัญของการ onboard contributors ใหม่และทำให้การถ่ายทอดความรู้เกิดขึ้นได้อย่างมีประสิทธิภาพ

เปิดกว้างสำหรับทุกคน

สิ่งที่ทำให้ระบบนี้แตกต่างจาก open source projects อื่นๆ คือการยอมรับว่า Project goals สามารถมาจากคนนอก Rust teams ได้ นิยามของ Project goal คือข้อตกลงระหว่าง owner ที่จะทำงาน และ team ที่จะรับงานนั้น โดย owners อาจเป็นหรือไม่เป็นสมาชิกของ Rust team ก็ได้ ระบบจะรับเฉพาะ goals ที่มีทั้ง owner(s) ที่จะทำงาน และ team(s) ที่ต้องการงานนั้น การที่ team(s) เห็นชอบกับ goal นั้นเองที่ทำให้มันกลายเป็น Rust Project goal อย่างแท้จริง นี่คือการเปิดกว้างที่แท้จริง ไม่ใช่แค่คำพูด แต่มาพร้อมกับโครงสร้างที่รองรับให้ความร่วมมือนั้นเกิดขึ้นได้จริง

Timeline 2026

Timeline ของกระบวนการนี้ถูกวางแผนอย่างชัดเจนและโปร่งใส ในแต่ละเดือน งานจะเริ่มต้นตั้งแต่ต้นเดือนและดำเนินการตลอดทั้งเดือน:

  • มกราคม: เป็นช่วงของการรวบรวม goal proposals และเขียน draft แรก
  • กุมภาพันธ์: ซึ่งเป็นช่วงที่เรากำลังอยู่ตอนนี้ เป็นช่วงของการรับ feedback และเตรียม RFC
  • มีนาคม: จะเป็นการเปิด RFC และทำการ merge โดย RFC นี้ต้องได้รับการอนุมัติจาก leads ของทุกทีมที่มี “team ask” ระบุไว้ใน goal ใดๆ ก็ตาม
  • เมษายน: จะเป็นการประกาศ 2026 Project Goals อย่างเป็นทางการ กระบวนการนี้แสดงให้เห็นถึงความใส่ใจในการสร้าง consensus และให้เวลาทุกฝ่ายได้พิจารณาอย่างรอบคอบ

ยังไม่สายเกินไปที่จะมีส่วนร่วม

สิ่งที่น่าตื่นเต้นสำหรับคนที่กำลังคิดจะมีส่วนร่วมคือคุณยังไม่สายเกินไปที่จะเสนอ goal ของคุณเอง แม้ว่าเราจะอยู่ในเดือนกุมภาพันธ์แล้วก็ตาม Rust Project รับ goal proposals ตลอดทั้งปี แต่สำหรับ goals ที่มาในช่วงปลายปี รวมถึงกุมภาพันธ์ จะต้องมี champion พร้อมแล้วและมี buy-in จากทีม แน่นอนว่าในฐานะสมาชิกทีม คุณสามารถ champion goal ของตัวเองภายในทีมของคุณได้ และที่น่าสนใจยิ่งขึ้นคือถ้าคุณต้องการ funding เพื่อทำงานใน goal ของคุณ มี funding available สำหรับทั้ง Project goals และ champions ของ Project goals โดยสามารถติดต่อ Niko Matsakis เพื่อหารือได้

บทสรุป

การเปลี่ยนแปลงครั้งนี้สะท้อนถึงวุฒิภาวะของ Rust Project ที่กำลังเติบโตจากภาษาโปรแกรมมิ่งหนึ่งไปสู่ ecosystem ที่สมบูรณ์ การมีระบบ goals ที่ชัดเจน ระบบ champion ที่สนับสนุน และ flagship themes ที่ให้ทิศทาง ทั้งหมดนี้ทำงานร่วมกันเพื่อสร้างความยั่งยืน ความโปร่งใส และความเป็น inclusive ที่แท้จริง

สำหรับ Rust developers ที่ทำงานกับภาษานี้อย่างจริงจัง การติดตาม goals เหล่านี้ไม่ใช่แค่การรู้ว่าอนาคตจะเป็นอย่างไร แต่เป็นโอกาสในการมีส่วนร่วมกำหนดอนาคตนั้นด้วยตัวเอง

ถ้าคุณสนใจที่จะร่วมแสดงความคิดเห็น มีคำถาม หรือต้องการเสนอแนะอะไร สามารถเปิด topic ใน project-goals/2026-workshop channel ได้ทันที เพราะตอนนี้คือช่วงเวลาที่ Rust community กำลังหล่อหลอมอนาคตของภาษาที่เรารักร่วมกัน และทุกเสียงมีความสำคัญในการสร้าง consensus ที่จะนำพาเราไปสู่ปี 2026 ที่น่าตื่นเต้นครับ

Credit & Reference:

  1. First look at 2026 Project goals

Rust Web

ยังไม่มีบทความในหมวดหมู่นี้