DEV Community: Gophernment

REPL — วิธีคุยกับคอมพิวเตอร์ที่ LISP สอนโลก

Gophernment — Wed, 05 Aug 2026 10:14:29 +0000

คุณเคยนึกไหมว่าก่อนที่จะมี >>> ใน Python,
ก่อน node console,
ก่อน Chrome DevTools —

การคุยกับคอมพิวเตอร์มันเป็นยังไง?

คำตอบคือ... คุณไม่ได้คุยกับมัน คุณเขียนโปรแกรมทั้งก้อนบน punch card, ยัดเข้าเครื่อง, รอ output ออกมา, แล้วค่อยรู้ว่ามี bug หรือเปล่า

REPL เปลี่ยนทั้งหมดนั้น

READ → EVAL → PRINT → LOOP

REPL ย่อมาจาก Read-Eval-Print Loop — วงจรง่าย ๆ สี่ขั้นตอน:

1. READ   — อ่านสิ่งที่คุณพิมพ์
2. EVAL   — ประมวลผลมัน
3. PRINT  — แสดงผลลัพธ์
4. LOOP   — กลับไปรอ input ถัดไป

วงจรนี้เกิดจาก LISP ในทศวรรษ 1960s — read, eval, และ print คือ primitive function สามตัวของภาษา

เวลาเราเฉลิมฉลอง LISP เรามักพูดถึง garbage collection, lambda, macro — แต่ REPL ต่างออกไป

REPL ไม่ใช่ "feature"... มันคือ วิธีคิด

ก่อน REPL: ยุคที่คอมพิวเตอร์ไม่คุยกับคุณ

ลองนึกภาพ programmer ปี 1965:

เขียนโค้ดบนกระดาษ
เจาะ punch card
ยื่นให้ operator
รอคิว (อาจเป็นชั่วโมง หรือเป็นวัน)
เครื่องรัน
ได้ output
เจอ bug — กลับไปข้อ 1

นี่คือ batch processing — ทั้งวงการเป็นแบบนี้

ลองเทียบกับวันนี้: คุณพิมพ์ 2 + 2 → enter → 4 ปรากฏในเสี้ยววินาที

REPL ทำให้วงจร feedback จาก "เป็นวัน" เหลือ "เป็นวินาที"

นี่คือการเปลี่ยน paradigm ที่ใหญ่กว่า feature ใด ๆ ที่ LISP คิด — มันเปลี่ยนวิธีที่มนุษย์ interact กับคอมพิวเตอร์ จาก "สั่งแล้วรอ" เป็น "สนทนา"

กำเนิดในห้องแล็บ AI ของ MIT

read-eval-print loop ไม่ได้เกิดจาก philosophy หรือ manifesto — มันเกิดจากความจำเป็น

AI researchers ที่ MIT กำลังเขียนโปรแกรมที่ต้องลองผิดลองถูกตลอดเวลา เขียนโปรแกรมทั้งก้อนไม่ได้ — เพราะยังไม่รู้ด้วยซ้ำว่าอยากให้มันทำอะไร

พวกเขาต้องการ ทดลองทีละ expression — เห็นผลลัพธ์ทันที แล้วปรับสมมติฐาน

LISP — ด้วยความที่ทุกอย่างเป็น expression, ทุก expression ให้ผลลัพธ์ — เหมาะกับวิธีนี้อย่างเป็นธรรมชาติ

คำว่า "read-eval-print loop" ปรากฏครั้งแรกใน MACLISP Reference Manual (1974, David Moon)
แต่หลักการนี้ถูกใช้จริงมาตั้งแต่ LISP I system ในปี 1960 (LISP 1.5 Programmer's Manual ปี 1962 คือฉบับที่สมบูรณ์และแพร่หลายที่สุดในยุคนั้น)

ทำไม REPL ถึงสำคัญกว่า "แค่ console"

REPL ไม่ใช่แค่ terminal ที่พิมพ์คำสั่งได้ มันเปลี่ยนวิธีที่เรา:

วิธีเก่า	วิธี REPL
อ่าน documentation → ท่องจำ → เขียน	ทดลอง → ดูผล → เข้าใจ
รอ compile ทั้งโปรเจกต์	ทดสอบทีละฟังก์ชัน
กลัวผิด เพราะแก้ยาก	ผิดได้เร็ว แก้ได้เร็ว
code คือ artifacts สำเร็จรูป	code คือ conversation

นี่คือรากฐานของ exploratory programming — ปรัชญาที่บอกว่าเราไม่จำเป็นต้องรู้ทุกอย่างก่อนเริ่มเขียน เราเรียนรู้ระหว่างเขียนได้

การเดินทางของ REPL — จากห้องแล็บ AI มาถึงมือคุณ

1960s — LISP

REPL ตัวแรกของโลก — read, eval, print ในวงจรอนันต์

1990–1991 — Python

Guido van Rossum เริ่มพัฒนา Python ปลายปี 1989 เปิดตัวสู่สาธารณะครั้งแรกในเดือนกุมภาพันธ์ 1991 — REPL (>>>) เป็นส่วนหนึ่งของภาษามาตั้งแต่แรก โดยเอาไอเดียมาจาก LISP และ ABC language (ภาษาที่ Guido ช่วยพัฒนาก่อนหน้านี้)

สิ่งที่ Python เพิ่ม: readability — REPL ที่อ่านง่าย, error message ที่มนุษย์เข้าใจ, และ philosophy "มาเพื่อให้คนเขียน, ไม่ใช่ให้ compiler อ่าน"

1995 — Ruby IRB

Matz สร้าง IRB (Interactive Ruby) — สำหรับคนที่อยากลอง Ruby แบบ real-time (Ruby มี DNA LISP — Matz บอกว่า "Ruby was a Lisp originally, in theory")

2006 — Firebug

Joe Hewitt สร้าง Firebug extension สำหรับ Firefox — เป็นครั้งแรกที่ browser มี interactive console แบบ REPL: inspect DOM, ทดลอง JavaScript, ดู network request — ทั้งหมดใน browser โดยไม่ต้องเปิด terminal แยก วงการ frontend dev เปลี่ยนไปตลอดกาล

2009 — Node.js REPL

Ryan Dahl ให้ JavaScript มี REPL นอก browser — frontend dev สามารถลอง JS แบบ interactive โดยไม่ต้องเปิด browser เลย

2011 — Chrome DevTools Console

ทีม Chrome ของ Google ต่อยอดจาก WebKit Inspector (ต้นแบบของ Safari) สร้าง DevTools ที่มี Console ในตัว — แนวคิด interactive debugging ใน browser ที่ Firebug บุกเบิกไว้ กลายเป็น standard ในทุก browser หลังจากนั้น

2014 — IPython / Jupyter Notebook

Fernando Pérez ต่อยอด REPL ของ Python ให้เป็น notebook — ผสมโค้ด, ผลลัพธ์, markdown, กราฟ ในหน้าเดียว นี่คือ REPL เวอร์ชันที่สมบูรณ์แบบที่สุดสำหรับ data science

2015 — Rust Playground

Rust — ภาษาที่ compile ช้าเป็นชั่วโมง — มี playground ออนไลน์ที่ทำตัวเป็น REPL: เขียน → รัน → เห็นผล → ปรับ → รันใหม่ — ทั้งหมดใน browser

สิ่งที่ REPL สอนเรา

Feedback loop ที่สั้นที่สุดคืออาวุธที่ทรงพลังที่สุด — programmer ที่ทดลองเร็ว เรียนรู้เร็วกว่า programmer ที่รอ compile
ภาษาไม่ควร "ถูกต้องตั้งแต่ compile" ควร "เรียนรู้ระหว่างเขียน" — REPL ทำให้ภาษากลายเป็นเครื่องมือคิด ไม่ใช่แค่เครื่องมือผลิต
Simple ideas win — read → eval → print → loop — 4 คำ, 4 ขั้นตอน, เปลี่ยนวิธีมนุษย์เขียนโค้ดไปตลอดกาล

อ่านเพิ่ม

MACLISP Reference Manual (1974) — ที่มาของคำว่า "read-eval-print loop"
Paul Graham — "Revenge of the Nerds" — "Lisp was the first language to have an interactive REPL"
Bret Victor — "Inventing on Principle" — ทำไม feedback ที่ทันทีถึงเปลี่ยนวิธีเราคิด
Jupyter Project — REPL สำหรับ data science

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

LISP — ภาษา 67 ปีก่อน ที่ยังมีชีวิตอยู่ในทุกภาษาที่คุณเขียน

Gophernment — Tue, 04 Aug 2026 23:13:21 +0000

คุณเขียน if-else ทุกวัน
คุณรัน code ใน terminal แล้ว REPL มันตอบกลับมา
คุณ lambda ใน Python, arrow function ใน JavaScript, closure ใน Rust

— ทั้งหมดนี้ เกิดจากภาษา LISP

และที่น่าทึ่งคือ... LISP ไม่เคยถูก planned ให้เป็นภาษาโปรแกรมด้วยซ้ำ

กระดาษแผ่นเดียวที่เปลี่ยนโลก

1958 — John McCarthy เริ่มพัฒนาแนวคิด LISP ที่ MIT
เมษายน 1960 — McCarthy วัย 32 ตีพิมพ์ paper ใน Communications of the ACM (vol. 3, หน้า 184-195)

"Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I"

ใน paper 12 หน้านี้ McCarthy เสนอไอเดียของภาษาโปรแกรมที่:

จัดการกับสัญลักษณ์ (symbols) ไม่ใช่แค่ตัวเลข
ใช้ recursion เป็นตัวควบคุมการทำงาน แทนการใช้ loop
เก็บ function เป็น first-class citizen — ส่งต่อกันได้เหมือนข้อมูล

McCarthy เขียนมันขึ้นมาเป็น ทฤษฎีทางคณิตศาสตร์ — ไม่ได้ตั้งใจ implement

แต่ก่อน paper จะตีพิมพ์ — ระหว่างปี 1958-59 Steve Russell นักศึกษา grad student อ่าน manuscript

"I told him, 'Steve, why don't you program this eval?' and he said to me, 'Oh, I misread what you meant. I thought you meant I should implement the interpreter.'"

— John McCarthy, ACM interview

นักศึกษา เขียน interpreter ให้ทฤษฎีของอาจารย์ — และภาษา LISP ก็เกิด

code ตัวแรกที่ Russell เขียน ใช้เวลาแค่ 2-3 วัน (ตัว LISP 1.5 Programmer's Manual ฉบับเต็มออกตามมาทีหลัง ในปี 1962)

สิ่งที่ LISP สร้างไว้ (และเราใช้มันทุกวัน)

1. if-then-else

ย้อนไปปี 1958 — ภาษาส่วนใหญ่มีแค่ GOTO กับ branch แบบ assembly

McCarthy ให้กำเนิด cond (conditional expression) — จุดเริ่มต้นของ if-else ที่เราเห็นแทบจะในทุกภาษา

(cond ((< x 0) 'negative)
      ((= x 0) 'zero)
      (t 'positive))

C, Java, Python, JavaScript, Go, Rust — ภาษาเหล่านี้ได้รับมรดกนี้มาหมด Conditional branching ในทุกภาษาสมัยใหม่มีโครงสร้างแบบเดียวกับที่ McCarthy คิดไว้ตั้งแต่ก่อนมนุษย์ไปดวงจันทร์

2. Garbage Collection

ก่อน LISP — programmer จัดการ memory เอง 100% ทุกบรรทัดของ malloc และ free

LISP สร้าง garbage collection ตัวแรกของโลก — ต้นฉบับคือ mark-and-sweep algorithm (implement โดย Daniel Edwards นักศึกษา MIT)

ทุกวันนี้ GC คือ default ในเกือบทุกภาษา high-level — Java, Python, JavaScript, Go, C#, Ruby ล้วนใช้แนวคิดนี้ต่อยอด

3. Lambda — function เป็นข้อมูล

(lambda (x) (* x x))

LISP ทำให้ function เป็น first-class citizen — ส่ง function เป็น parameter ได้, return function ได้, เก็บลง variable ได้เหมือนเป็น string หรือ integer

นี่คือต้นทางของ:

JavaScript — arrow function (x) => x * x (Brendan Eich ถูกจ้างไป Netscape เพื่อทำ Scheme ใน browser — แต่ management เปลี่ยนใจให้ syntax เหมือน Java)
Python — lambda x: x * x
Ruby — blocks, procs, lambdas (Matz บอกว่า "Ruby was a Lisp originally, in theory")
Java — lambda expressions (Java 8, 2014 — ใช้เวลา 19 ปีกว่าจะตามทัน)
C++ — lambda (C++11)

4. REPL — ปรัชญา "คุยกับภาษา"

Read-Eval-Print Loop — LISP ให้กำเนิดมันในทศวรรษ 1960s

ก่อนหน้านั้น: เขียน code → compile → run → debug → repeat
หลังจากนั้น: พิมพ์ expression → กด enter → เห็นผลทันที

ทุกวันนี้ถ้าคุณเปิด Python REPL (>>>), Node.js console, Ruby IRB, Chrome DevTools, Rust Playground, หรือ Elixir IEx — คุณกำลังนั่งอยู่ในห้องเรียนเดียวกับ programmer LISP เมื่อ 60 ปีที่แล้ว

5. Homoiconicity — code = data

'(+ 1 2)          ; ← นี่คือ list
(eval '(+ 1 2))   ; ← นี่คือ code ที่รัน list

LISP เขียนด้วย... LISP — code กับ data ใช้โครงสร้างเดียวกัน (S-expression)

แปลว่า โปรแกรมแก้โปรแกรมตัวเองได้ — ไม่ต้องใช้ parser แยก AST, ไม่ต้องเขียน transformer

นี่คือรากฐานของ macro system ที่ทรงพลังที่สุดในสายภาษาโปรแกรม

ไม่มีภาษาไหนทำได้เต็มระบบเท่า LISP — แต่แนวคิด "code as data" ไปอยู่ใน:

Elixir — macro (รับ AST, คืน AST)
Julia — macro + multiple dispatch ("We want a language that's homoiconic, with true macros like Lisp" — Julia manifesto, 2012)
Rust — macro system (proc macro)
Clojure — macro (ของ Clojure ก็คือ LISP dialect นั่นเอง)

มรดกจาก LISP

LISP (1958)
├── Scheme (1975) — minimalist, lexical scoping
│   ├── JavaScript (1995) — Brendan Eich ตั้งใจทำ Scheme-like ใน browser
│   │   └── arrow functions, closure, first-class functions
│   └── Racket (1995) — ภาษาเพื่อการสอนและการวิจัย
├── Common Lisp (1984) — ภาคอุตสาหกรรม, pragmatic
│   └── Emacs Lisp (1985) — editor scripting (GNU Emacs)
├── Clojure (2007) — LISP บน JVM, immutable by default
│   └── จุดประกาย functional programming ในโลก enterprise
└── Python, Ruby, Elixir, Julia, Rust, Swift — ทุกภาษาเอาแนวคิด LISP ไปปรับใช้

ทำไม LISP ถึงไม่ใช่ภาษาหลักวันนี้

ทั้งที่สร้างนวัตกรรมเกือบทุกอย่างที่เราใช้ — ทำไม LISP ถึงไม่ชนะ?

Paul Graham (ผู้ก่อตั้ง Y Combinator, แฟนพันธุ์แท้ LISP) อธิบายไว้ใน essay "Beating the Averages":

Syntax ต่างจากทุกอย่าง — วงเล็บทำให้คนกลัว
ไม่มี standard library ในยุคแรก — Common Lisp มากอบกู้ในปี 1984 แต่ช้าไปแล้ว
AI Winter — LISP ผูกกับ AI research; เมื่องบ AI หาย LISP ก็หายด้วย
Tooling — compiler ช้า, IDE ห่วย (เทียบกับ Visual Studio ยุค 90s)

Graham ยืนยันว่า:

"Lisp is a language that was discovered, not invented."

ฝั่งนักวิจารณ์ LISP (รวมถึงคนที่เคยใช้ใน production แล้วเปลี่ยนไปภาษาอื่น) ชี้ปัญหาเพิ่มเติมที่ Graham ไม่พูดถึง:

Dynamic typing ในระบบใหญ่ — refactoring ยาก, compiler จับ error ได้น้อย, debugging ใช้เวลานานใน codebase ระดับแสนบรรทัด
Performance จนถึงยุค 2000s — ก่อน SBCL และ Chez Scheme, LISP runtime บน hardware ยุคนั้นช้ากว่า C/C++ มากโดยเฉพาะงาน numerical
Fragmentation — Common Lisp กับ Scheme ไม่เคยตกลงกันได้; community แตกเป็นเสี่ยง ๆ แทนที่จะรวมพลัง

สรุป: ไม่มีสาเหตุเดียว — มันคือ perfect storm ของ syntax ต่าง + เกิดผิดเวลา + community แตก + ไม่มี corporate sponsor (ต่างจาก Java ที่ Sun ทุ่ม, C# ที่ Microsoft ทุ่ม)

มรดกที่มองไม่เห็น

บทความนี้ไม่ได้ตั้งใจจะบอกว่า "คุณควรเขียน LISP"

แต่ทุกครั้งที่คุณ:

numbers = [1, 2, 3]
squared = list(map(lambda x: x * x, numbers))

const result = data
  .filter(x => x.active)
  .map(x => x.value);

let squared: Vec<_> = numbers.iter().map(|x| x * x).collect();

— คุณกำลังเขียน LISP โดยไม่รู้ตัว

อ่านเพิ่ม

McCarthy's Original 1960 Paper — "Recursive Functions of Symbolic Expressions"
Paul Graham — "Beating the Averages"
Paul Graham — "Revenge of the Nerds"
Structure and Interpretation of Computer Programs (SICP) — ตำรา Scheme ในตำนานของ MIT
Rich Hickey — "Simple Made Easy" — ปรัชญาเบื้องหลัง Clojure

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

GNU — จุดเริ่มต้นของ Linux ที่หลายคนไม่เคยรู้

Gophernment — Tue, 04 Aug 2026 22:51:23 +0000

เวลาเราเรียก Linux — เรามักนึกถึงระบบปฏิบัติการที่รันเซิร์ฟเวอร์ 99% ของโลก รัน Android รัน Raspberry Pi แต่สิ่งที่หลายคนไม่รู้คือ Linux ไม่ใช่ "ระบบปฏิบัติการที่สมบูรณ์" ตั้งแต่แรก มันเป็นแค่ kernel — หัวใจที่คอยคุยกับฮาร์ดแวร์

ส่วน shell, compiler, text editor, core utilities — ทั้งหมดนั่นมาจาก โครงการ GNU

เรื่องราวของ GNU และ Linux มันเริ่มจากการที่เครื่องพิมพ์เครื่องหนึ่ง... พัง

📌 ออกเสียงอย่างไร: GNU อ่านว่า "กะ-นู" (hard g, พยางค์เดียว) — GNU's Not Unix

เรื่องเล่าจากเครื่องพิมพ์

ปี 1980 Richard Stallman ทำงานที่ MIT AI Lab เครื่องพิมพ์ Xerox ในห้องแล็บ jam กระดาษบ่อยมาก เขาเลยอยากแก้ซอฟต์แวร์ให้มันแจ้งเตือนตอน jam แต่ Xerox ไม่ยอมให้ source code

สำหรับคนยุค 2026 นี่คือเรื่องปกติ — บริษัทไม่ให้ source code ก็หาอันอื่นสิ

แต่สำหรับ Stallman และวัฒนธรรม hacker ใน MIT AI Lab ยุค 1970s — นี่คือการทรยศ

เพื่อนบ้าน hack รั้วบ้านคุณ และคุณไม่มีสิทธิ์แม้แต่จะรู้ว่ารั้วมันสร้างยังไง

Stallman เขียนไว้ในภายหลังว่า:

"ผมบอกตัวเองไม่ได้ว่า non-disclosure agreement มันไม่มีพิษมีภัย"

กำเนิด GNU

27 กันยายน 1983 — Stallman โพสต์ประกาศโครงการ GNU บน Usenet ภายใต้หัวข้อ "new Unix implementation"

"ผมเชื่อว่ากฎทอง (golden rule) กำหนดว่า ถ้าผมชอบโปรแกรมใด ผมต้องแบ่งปันมันกับคนอื่นที่ชอบมันด้วย ผมไม่สามารถเซ็นสัญญาไม่เปิดเผยข้อมูล (NDA) หรือสัญญาอนุญาตซอฟต์แวร์แบบปิด ด้วยจิตสำนึกที่ดีได้"

— Richard Stallman, GNU Initial Announcement, 27 ก.ย. 1983

เป้าหมาย: สร้างระบบปฏิบัติการแบบ Unix ที่ ทุกคนมีอิสระ ในการใช้ แก้ไข และแชร์

ฟรี ไม่ได้แปลว่า gratis (ของฟรี)
ฟรี แปลว่า libre (เสรีภาพ)

— Free Software Foundation

Stallman เริ่มเขียนทีละ component:

GNU Emacs — text editor ในตำนาน (1985)
GCC — GNU C Compiler (1987)
glibc — C library (1988)
Bash — shell ที่เราใช้กันมาจนถึงทุกวันนี้ (1989)
Coreutils, binutils, gdb... ไล่เรียงไปเรื่อย ๆ

ภายในปี 1990 — เกือบทั้งระบบปฏิบัติการพร้อมแล้ว ยกเว้น kernel

Hurd — kernel ที่ไม่มีวันเสร็จ

kernel ที่ GNU เลือกใช้คือ GNU Hurd — ออกแบบด้วยสถาปัตยกรรม microkernel บน Mach (CMU) ที่ทะเยอทะยานเกินยุค

ปัญหาคือ:

รอ Mach เป็น free software — CMU ล่าช้าในการปล่อย source code เพราะฝ่ายกฎหมาย
Multithreaded servers สื่อสารด้วย IPC — "very hard to debug" (คำพูดของ Stallman เอง)
Perfect is the enemy of good — ดีไซน์ซ้ำไปซ้ำมาเพื่อความ "สมบูรณ์แบบ" ทางทฤษฎี
Hurd 0.1 ออกปี 1996 — 6 ปีหลังจากเริ่มพัฒนา
Hurd 0.9 ออกธันวาคม 2016 — ล่าสุด และไม่เคยถึง 1.0

Stallman พูดตรง ๆ:

"GNU Hurd ไม่เหมาะสำหรับ production use และเราไม่รู้ว่ามันจะเหมาะเมื่อไหร่"

เด็กฟินแลนด์กับ kernel ของเขา

25 สิงหาคม 1991 — Linus Torvalds นักศึกษาปี 2 มหาวิทยาลัย Helsinki (อายุ 21 ปี) โพสต์บน Usenet group comp.os.minix:

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.

สังเกตว่า Linus เองก็พอร์ต bash และ gcc — GNU tools — มาตั้งแต่วันแรก

17 กันยายน 1991 — Linux 0.01 ออกสู่สาธารณะ (คนที่ตั้งชื่อว่า "Linux" คือ Ari Lemmke ผู้ดูแล ftp.funet.fi — Linus อยากให้ชื่อ "Freax" แต่ Lemmke ไม่ชอบ)

Linus เขียนใน release notes ของ 0.01:

"Sadly, a kernel by itself gets you nowhere… Most of the tools used with linux are GNU software and are under the GNU copyleft."

"น่าเศร้าที่ kernel อย่างเดียวมันไปไหนไม่ได้... เครื่องมือส่วนใหญ่ที่ใช้กับ linux คือซอฟต์แวร์ GNU"

ทำไม Linux ถึงสำเร็จ

ทั้งที่ Hurd มีคนเก่งกว่า มี philosophy ล้ำกว่า ทำไม Linux ถึงชนะ?

	GNU Hurd	Linux
สถาปัตยกรรม	Microkernel	Monolithic
ออกแบบโดย	นักทฤษฎี OS	"ค่าเทอมถูกกว่า Sun"
ปรัชญา	Perfect from day 1	Release early, release often
ทีม	อาสาสมัคร	ชุมชน (Git แจกตั้งแต่ 2005)

"Release early, release often" — หลักการที่ Linus สอนโลก open source โดยไม่ตั้งใจ

Linux 0.01 (ก.ย. 1991) — ~10,000 บรรทัด
Linux 0.12 (ก.พ. 1992) — เปลี่ยนไปใช้ GPL — นี่คือจุดเปลี่ยนสำคัญ
Linux 1.0 (มี.ค. 1994) — 176,250 บรรทัด
Linux 6.x (2024) — เกิน 30 ล้านบรรทัด

GNU + Linux = ?

เมื่อ Linux ถือกำเนิด มันขาด userspace tools — shell, compiler, basic utilities

GNU มีของทุกอย่าง — GCC compiler, Bash shell, coreutils

Linux + GNU tools = ระบบปฏิบัติการที่สมบูรณ์ ครั้งแรกที่โลกมี free Unix ทั้งระบบ

"It is due to Linux that we can actually run a version of the GNU system today."

— Richard Stallman

MCC Interim Linux (กุมภาพันธ์ 1992) — ผลงานของ Owen Le Blanc จาก Manchester Computing Centre — คือ distro แรกที่รวม Linux kernel กับ GNU userspace เข้าด้วยกัน ตามด้วย TAMU Linux และ SLS (Softlanding Linux System) ในสิงหาคม 1992

SLS เป็น distro แรกที่คนใช้กันเยอะ... แต่ package management ของมันพังไม่เป็นท่า จนทำให้ Ian Murdock วัย 20 ปี ประกาศบน Usenet ในเดือนสิงหาคม 1993 ว่าจะสร้าง distro ใหม่ที่ "maintained openly, in the spirit of GNU" — distro นั้นคือ Debian

ตามมาด้วย Slackware (กรกฎาคม 1993) ที่พัฒนาโดย Patrick Volkerding — เรียบง่าย ไม่มี dependency resolution แต่ stable จนกลายเป็น distro ที่เก่าแก่ที่สุดที่ยัง maintain อยู่จนถึงทุกวันนี้

เมื่อ Debian เปลี่ยนชื่อเป็น "Debian GNU/Linux" ในต้นปี 1994 ตามคำขอของ Stallman — การถกเถียงเรื่องชื่อก็เริ่มต้นขึ้น

GNU/Linux — การถกเถียงที่ยังไม่จบ

Stallman ยืนกราน: เรียกมันว่า "GNU/Linux" เพราะ:

GNU project เริ่มตั้งแต่ 1983 — 7-8 ปีก่อน Linux
Stallman อ้างอิงตัวเลขจากงานวิจัยภายในของ Red Hat (2001) และ gNewSense (2008) ว่า ใน distro หนึ่ง ๆ: โค้ด GNU ≈ 15-28%, โค้ด Linux kernel ≈ 1.5-3% (ตัวเลขนี้เป็นที่ถกเถียงในชุมชน — วัดยังไงให้นับ "หน่วย" ของโค้ดอย่างเที่ยงตรง)
ถ้าไม่มี GNU — Linus ต้องเขียน compiler, shell, utilities เองทั้งหมด

Linus ตอบกลับ:

"It doesn't really matter what people call Linux, as long as credit is given where credit is due."
— comp.os.linux.misc, 1996

และในหนังสารคดี Revolution OS (2001):

"Calling Linux in general 'GNU Linux' I think is just ridiculous."

แต่ Linus ก็ไม่ได้ดูถูก GNU — ในหนังสืออัตชีวประวัติ Just for Fun (2001) เขาเขียนว่า:

"Richard Stallman is the God of Free Software."

"Stallman, who deserves a monument in his honor for giving birth to the GPL…"

มรดกที่เรายังใช้อยู่ทุกวันนี้

ลองเปิด terminal แล้วพิมพ์:

$ ls --version | head -1
ls (GNU coreutils) 9.x

$ gcc --version | head -1
gcc (GCC) 14.x

$ bash --version | head -1
GNU bash, version 5.x

GNU คือวิญญาณของ Linux — kernel คือหัวใจ แต่ shell, compiler, utilities ที่เราใช้ทุกวันนี้ คือ GNU

ถ้าไม่มีโครงการ GNU: Linus ต้องเขียนทุกอย่างเองตั้งแต่ compiler, linker, shell... และ kernel "งานอดิเรก" ของเขาคงไม่รอด

และถ้าไม่มี Linux: GNU มีเกือบทุกอย่างยกเว้น kernel ที่รันได้จริง — Hurd ก็ยังเป็น prototype มาจนถึงทุกวันนี้

สองโครงการ — หนึ่งปรัชญา หนึ่ง pragmatic — มาบรรจบกันในเวลาที่เหมาะสมพอดี

สำหรับคนที่อยากอ่านเพิ่ม

The GNU Manifesto (1985) — Stallman ต้นฉบับ
The GNU Project — essay ของ Stallman
Linux 0.01 Release Notes — Torvalds, 1991
Linux 0.12 Release Notes (เปลี่ยนไปใช้ GPL) — Torvalds, ก.พ. 1992
Linus โพสต์แรกบน Usenet (25 ส.ค. 1991) — เก็บใน Wayback Machine
Just for Fun — Linus Torvalds autobiography (2001)
Revolution OS — หนังสารคดี open source

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

"iota ใน Go — อักษรกรีกตัวจิ๋วที่กลายเป็นเครื่องมือทรงพลัง"

Gophernment — Sun, 02 Aug 2026 03:53:36 +0000

📅 เขียนเมื่อ: กรกฎาคม 2026
⚠️ ตรวจสอบข้อมูลจาก Go Specification, APL documentation, และบันทึกของผู้พัฒนา

ถ้าคุณเขียน Go มาระยะหนึ่ง คุณคงเคยเห็น iota — เจ้า identifier ประหลาดที่ไม่มีใครรู้ว่ามันคืออะไรตอนเจอครั้งแรก

const (
    Monday = iota + 1  // 1
    Tuesday            // 2
    Wednesday          // 3
)

มันไม่ใช่ keyword, ไม่ใช่ type, ไม่ใช่ function — มันคืออะไรกันแน่?

และที่สำคัญ — ทำไมต้องชื่อ iota?

คำตอบพาเราย้อนกลับไปถึงปี 1962 — ถึงนักคณิตศาสตร์ชาวแคนาดาคนหนึ่ง และภาษาโปรแกรมมิ่งที่เปลี่ยนโลก

iota คืออะไรใน Go

ใน Go spec — iota คือ predeclared identifier ที่ใช้ เฉพาะใน const declaration เท่านั้น

มันทำสิ่งเดียว: นับเลขให้อัตโนมัติ

const (
    _ = iota          // 0 (skip)
    KB = 1 << (10 * iota)  // 1 << 10 = 1024
    MB                    // 1 << 20 = 1,048,576
    GB                    // 1 << 30
)

ค่า iota เริ่มที่ 0 และเพิ่มทีละ 1 ทุกครั้งที่เจอบรรทัดใหม่ใน const block — แม้ว่าบรรทัดนั้นจะไม่ได้ใช้ iota ก็ตาม

สิ่งที่ทำให้ iota ทรงพลังคือมันเป็น expression (ไม่ใช่แค่ตัวเลข) — คุณเอาไปคูณ บวก ลบ shift ได้หมด

const (
    Read    = 1 << iota  // 1 << 0 = 1
    Write                 // 1 << 1 = 2
    Execute               // 1 << 2 = 4
)

นี่คือวิธีมาตรฐานในการสร้าง enum, bitmask, และ constant series ใน Go — ทั้งหมดด้วย keyword เดียว

iota — อักษรกรีกตัวเล็กที่สุด

ก่อนจะเป็นชื่อใน Go — ιώτα (iota) คืออักษรตัวที่ 9 ของกรีกโบราณ: ι

มันคืออักษรที่ เล็กที่สุด ในภาษากรีก — แค่เส้นตรงหนึ่งเส้น ไม่มีหาง ไม่มีขีด

ในพระคัมภีร์ไบเบิล มีวลี famous: "not one iota" — แปลว่า "ไม่แม้แต่นิดเดียว" — เพราะ iota คือสิ่งที่เล็กที่สุด

และมันคือชื่อที่สมบูรณ์แบบสำหรับสิ่งที่ "เพิ่มทีละหนึ่ง"

จุดเริ่มต้น — APL และ Kenneth Iverson

นักคณิตศาสตร์ผู้สร้างภาษา

ปี 1962 — Kenneth E. Iverson ตีพิมพ์หนังสือ "A Programming Language" (ที่มาของชื่อ APL)

Iverson เป็นนักคณิตศาสตร์ชาวแคนาดา (ต่อมาได้ Turing Award ปี 1979) — เขาไม่ได้แค่ออกแบบภาษาใหม่ แต่ปฏิวัติวิธีคิดเรื่อง programming

แทนที่จะเขียน for i = 1 to 10 — Iverson คิดว่า programming ควรเหมือนคณิตศาสตร์: สั้น, สัญลักษณ์, และทรงพลัง

เกิดเป็น ⍳ (iota)

ใน APL, Iverson สร้าง operator ⍳ — เรียกว่า iota — ที่ทำสิ่งเดียว: สร้างลำดับเลข

⍳5    →  1 2 3 4 5
⍳10   →  1 2 3 4 5 6 7 8 9 10

(เชื่อกันว่าใน APL ดั้งเดิม ใช้ตัวอักษรกรีก ι จริง ๆ — Iverson notation ยุค 1957 ใช้สัญลักษณ์คณิตศาสตร์แบบกรีก ก่อนที่ APL จะพัฒนาชุดอักขระเฉพาะของตัวเอง จนได้สัญลักษณ์ ⍳ ที่เราเห็นใน APL สมัยใหม่)

ทำไมต้องชื่อ iota? — Iverson เลือกเพราะมันคือ อักษรที่เล็กที่สุด → เหมาะกับ operator ที่สร้าง "สิ่งที่เล็กที่สุด" (integer unit)

ปรัชญาของ Iverson: โปรแกรมมิ่งคือภาษาสำหรับ คิด — ไม่ใช่แค่ภาษาสำหรับ บอกคอมพิวเตอร์ให้ทำงาน

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

และ ⍳ (iota) คือหัวใจของแนวคิดนี้ — สร้างลำดับจากความว่างเปล่า ด้วยสัญลักษณ์เดียว

สิ่งที่ APL iota ทำได้ — มากกว่าแค่นับเลข

APL iota ไม่ได้สร้างแค่ 1 2 3 — มันสร้างได้ทุกมิติ:

⍳3 3   →  matrix 3×3 ของเลข 1..9
⍳2 3 4 →  array 3 มิติ

และเมื่อรวมกับ operator ตัวอื่นของ APL — ⍳ กลายเป็นอาวุธที่ทรงพลังอย่างไม่น่าเชื่อ:

+/⍳100   →  5050   (ผลรวม 1..100 — ใน 4 ตัวอักษร)

+/⍳100 — สี่ตัวอักษร คำนวณผลรวม 1 ถึง 100 — โค้ดที่ภาษาอื่นต้องใช้ loop

นี่คือเหตุผลที่ APL ถูกเรียกว่า "ภาษาโปรแกรมมิ่งที่ทรงพลังที่สุดต่อจำนวนตัวอักษร"

จาก APL สู่ Bell Labs — เส้นทางของ iota

Ken Thompson กับ APL

ช่วงปลายยุค 60 — Ken Thompson (ผู้สร้าง Unix) เป็นคนหนึ่งที่หลงรัก APL

เขาเขียน APL interpreter ด้วยตัวเอง — เช่นเดียวกับสมาชิกทีม Go อีกสองคน (Rob Pike และ Robert Griesemer) ที่ต่างคนต่างเคยเขียน APL interpreter มาก่อนเช่นกัน นี่คือจุดร่วมสำคัญที่ทำให้ทั้งสามคน "พูดภาษาเดียวกัน" เมื่อถึงเวลาออกแบบ Go

มีบันทึกว่า Thompson เคยพูดว่า APL เป็นหนึ่งในแรงบันดาลใจสำคัญในการออกแบบ Unix philosophy — "ทำสิ่งเดียวแต่ทำให้ดี"

เขาไม่ได้เอา APL syntax มาใช้ (Unix กับ Go ต่างจาก APL คนละขั้ว) — แต่เขาเอา วิธีคิด มา: abstraction ที่ทรงพลัง, ความกระชับ, และความงามทางคณิตศาสตร์

Bell Labs — แหล่งรวมคนที่รู้จัก iota

Bell Labs ช่วงยุค 70-80 คือสถานที่ที่รวมตัวนักคณิตศาสตร์-โปรแกรมเมอร์ที่เข้าใจ APL:

Ken Thompson — ผู้สร้าง Unix, เขียน APL interpreter เอง
Rob Pike — โตมาในยุคที่ APL เป็นตำนาน, เขียน APL interpreter เอง
Robert Griesemer — ผู้ร่วมสร้าง Go, ก็เขียน APL interpreter ด้วยตัวเองเช่นกัน

นี่คือเหตุผลที่แท้จริงที่ทำให้ชื่อ iota รู้สึก "ใช่" สำหรับทั้งทีม — ไม่ใช่แค่คนใดคนหนึ่งเสนอแล้วคนอื่นพยักหน้าตาม แต่ทั้งสามคนเข้าใจว่ามันคืออะไรและมาจากไหน

ทุกคนในทีมที่สร้าง Unix, Plan 9, และต่อมา Go — รู้ว่า iota คืออะไรและมาจากไหน

แนวคิด "sequence generator" ในตระกูล Unix

ระหว่างทางจาก APL สู่ Go — แนวคิด iota ไม่ได้หายไป:

C language (1972): enum — สร้าง constant sequence ได้ แต่ต้องประกาศชื่อ
Plan 9 C: ปรับปรุง enum ให้ cleaner ขึ้น
Limbo (Inferno OS): constant declaration ที่ใกล้เคียง Go มากขึ้น

Pike และทีมเห็นว่า — การสร้าง enum/constant series ใน C น่าเบื่อและ verbose — ต้องเขียนเลขเองทุกบรรทัด

// C — ต้องเขียนเลขเอง
enum {
    READ  = 1 << 0,
    WRITE = 1 << 1,
    EXEC  = 1 << 2,
};

เมื่อถึงเวลาออกแบบ Go — Pike รู้ดีว่าต้องมีอะไรดีกว่านี้

iota ใน Go — เกิดได้ยังไง

ปัญหาที่ต้องแก้

ทีม Go (Pike, Thompson, Griesemer) เริ่มออกแบบ Go ในปี 2007 — หนึ่งในเป้าหมายคือ: "ทำทุกอย่างให้ง่ายกว่า C"

constant declaration ใน C/C++ เป็นหนึ่งใน pain point:

ต้องเขียนค่าให้ทุก constant — แม้มันจะ predictable
enum กับ #define อยู่คนละโลก
bitmask/enum pattern ทำซ้ำซาก

ทีมต้องการอะไรที่:

กระชับ — ไม่ต้องเขียนเลขซ้ำ
flexible — ใช้กับ expression ได้ ไม่ใช่แค่ +1
ไม่ใช่ magic — อ่านแล้วเข้าใจทันทีว่าเกิดอะไรขึ้น

ตัวเลือกที่ทีมไม่เอา

Auto-increment แบบ enum — ใช้ได้แค่ +1, ทำ bitmask ไม่ได้
Preprocessor macro — Go ไม่มี preprocessor (ตั้งใจ)
Code generation — ซับซ้อนเกินสำหรับของง่าย ๆ

iota — ทางสายกลาง

Pike เสนอ iota — constant generator ที่:

Reset ทุก const block — scope ชัดเจน
เป็น expression — เอาไปคำนวณต่อได้
Reset เมื่อมี const keyword ใหม่ — predictable

const (
    _  = iota             // 0
    KB = 1 << (10 * iota)  // 1 << 10 = 1024
    MB                     // 1 << 20
    GB                     // 1 << 30
)

ส่วนชื่อ — ไม่ต้องคิดนาน: มันคือการยกย่อง (homage) ให้ APL — ภาษาที่สร้างแรงบันดาลใจให้กับคนสร้าง Unix, Plan 9, และ Go

วิธีใช้ iota แบบต่าง ๆ

1. Enum พื้นฐาน

type Season int

const (
    Spring Season = iota  // 0
    Summer                // 1
    Autumn                // 2
    Winter                // 3
)

2. Bitmask

type Permission uint8

const (
    Read    Permission = 1 << iota  // 1
    Write                           // 2
    Execute                         // 4
    Admin                           // 8
)

// ใช้:
var perm Permission = Read | Write  // 3

3. Skip values

const (
    _ = iota          // 0 (skip)
    Monday            // 1
    Tuesday           // 2
    Wednesday         // 3
    Thursday          // 4
    Friday            // 5
    Saturday          // 6
    Sunday            // 7
)

4. Multiple expressions ในบรรทัดเดียวกัน

const (
    bit0, mask0 = 1 << iota, 1<<iota - 1  // 1, 0
    bit1, mask1                           // 2, 1
    bit2, mask2                           // 4, 3
)

5. Jump pattern

const (
    a = iota * 2    // 0
    b               // 2
    c               // 4
    d               // 6
)

ทำไม iota ถึง "ใช่" สำหรับ Go

1. Philosophy match

Go มีหลักการ "หนึ่งวิธีที่ดีที่สุด" (one way to do it) — ต่างจาก Python ("หลายวิธีก็ดี") และ C++ ("มีทุกวิธี")

iota คือ "หนึ่งวิธี" ในการสร้าง enum/constant series — ใน Go คุณไม่ต้องเลือกว่าจะใช้ #define, enum, หรือ constexpr — มีแค่ iota

2. Zero cost abstraction

iota ไม่มี overhead — มันถูก resolve ตอน compile — runtime ไม่รู้ด้วยซ้ำว่ามี iota อยู่

3. Readability

เมื่อคุณเห็น iota — คุณรู้ทันทีว่า "อ๋อ ชุดนี้เป็นลำดับ"

const (
    Info = iota
    Warning
    Error
)

vs C:

enum {
    INFO = 0,
    WARNING,
    ERROR
};

น้อยกว่า — แต่บอกอะไรได้มากกว่า

4. Connection to history

iota เป็นหนึ่งใน easter egg ที่สวยงามของ Go — มันเชื่อมต่อกับ:

APL (1962) — ต้นกำเนิด
Bell Labs — สถานที่ที่ Thompson, Ritchie, Pike ทำงาน
Unix philosophy — ทำสิ่งเดียวให้ดี

นอกเรื่องนิดหน่อย — iota ในภาษาอื่น

หลังจาก Go ใช้ iota — หลายภาษาเริ่ม implement concept คล้าย ๆ กัน:

Rust: ไม่มี iota โดยตรง แต่ enum + #[repr] + strum crate ให้ความสามารถใกล้เคียง
Zig: enum มี auto-increment แต่ไม่ flexible เท่า iota
Swift: enum รองรับ raw value แต่ต้องระบุ type

ไม่มีใครทำได้สะอาดเท่า Go — เพราะไม่มีใครกล้าใช้ชื่อ iota (หรืออาจเพราะไม่มีใครรู้ว่ามันคืออะไร)

สิ่งที่ iota สอนเรา

ชื่อดีเปลี่ยนทุกอย่าง

iota ใน Go ทำแค่ auto-increment — เหมือน __COUNTER__ ใน C, enumerate ใน Python

แต่เพราะชื่อมัน — iota กลายเป็นมากกว่า feature: มันคือ เรื่องราว

ทุกครั้งที่โปรแกรมเมอร์ Go สงสัยว่า "iota คืออะไร" — พวกเขาย้อนกลับไปถึง APL, ถึง Kenneth Iverson, ถึง Bell Labs, ถึงประวัติศาสตร์ของภาษาโปรแกรมมิ่ง

และนั่นคือสิ่งที่ภาษาโปรแกรมมิ่งที่ดีทำ — ไม่ใช่แค่แก้ปัญหา แต่ เล่าเรื่อง

สรุป

iota เริ่มจากอักษรกรีกตัวเล็กที่สุด → กลายเป็น operator ใน APL (1962) → ถูกจดจำโดยทีม Bell Labs → และมาอยู่ใน Go ในฐานะ homage ให้กับประวัติศาสตร์ของ programming

มันใช้เวลา 50 ปี — จากแนวคิดทางคณิตศาสตร์ สู่ภาษาโปรแกรมมิ่งที่ใช้ใน production ทั่วโลก

และทั้งหมดเริ่มจากสัญลักษณ์เดียว: ι

// 50 ปีของการเดินทาง — ใน 4 บรรทัด
const (
    APL    = iota  // 1962
    Unix           // 1969
    Go             // 2009
)

ที่มา: Go Language Specification, "A Programming Language" โดย Kenneth Iverson (1962), Rob Pike's talks on Go design, Bell Labs oral history, APL Wiki

"Plan 9 — ระบบปฏิบัติการที่โลกลืม แต่เปลี่ยนวิธีคิดเรื่อง OS ไปตลอดกาล"

Gophernment — Sun, 02 Aug 2026 03:38:26 +0000

📅 เขียนเมื่อ: กรกฎาคม 2026
⚠️ อ้างอิงจากเอกสารต้นฉบับของ Bell Labs และบันทึกของผู้พัฒนา

ถ้าผมถามว่า "ระบบปฏิบัติการที่เจ๋งที่สุดในโลกคืออะไร" — คุณคงตอบ Linux, macOS, หรือ Windows

แต่ถ้าถาม Ken Thompson และ Dennis Ritchie — สองคนที่สร้าง Unix ขึ้นมา — พวกเขาจะตอบว่า Plan 9

Plan 9 คือระบบปฏิบัติการที่ Bell Labs สร้างขึ้นในช่วงปลายยุค 80 ถึงต้นยุค 90 โดยทีมเดียวกับที่สร้าง Unix แต่มันไม่ใช่แค่ "Unix เวอร์ชันใหม่" — มันคือการเริ่มต้นใหม่ทั้งหมด

และถึงแม้วันนี้แทบไม่มีใครใช้ Plan 9 — แนวคิดของมันแทรกซึมอยู่ในทุกระบบปฏิบัติการที่คุณใช้อยู่

จุดเริ่มต้น — "Unix เริ่มแก่แล้ว"

ปัญหาที่ Unix สะสมมา

Unix เกิดในปี 1969 — ตอนนั้นคอมพิวเตอร์คือเครื่องเดียวที่มี terminal ต่อพ่วง

พอยุค 80 มาถึง โลกเปลี่ยน — network กลายเป็นเรื่องปกติ, graphics เริ่มสำคัญ, distributed computing เริ่มเกิด

แต่ Unix ไม่ได้ถูกออกแบบมาเพื่อสิ่งเหล่านี้ มันถูก patch, extend, retrofit — จนกลายเป็นระบบที่ซับซ้อนเกินกว่าที่ผู้สร้างจะภูมิใจ

Ken Thompson เคยพูดประมาณว่า: "Unix เริ่มต้นด้วยความเรียบง่าย แต่มันค่อย ๆ สะสมความซับซ้อนเข้าไปเรื่อย ๆ — ถึงเวลาที่ต้องเริ่มใหม่"

ทำไมต้องชื่อ Plan 9

ชื่อ "Plan 9" มาจากหนัง B-movie สุดคลาสสิกเรื่อง "Plan 9 from Outer Space" (1959) ของ Ed Wood — ที่ได้ชื่อว่าเป็น "หนังที่แย่ที่สุดตลอดกาล"

แต่ชื่อนี้ไม่ได้หมายความว่า OS นี้แย่ — มันคือมุกวงในของทีม Bell Labs ที่ชอบตั้งชื่อแปลก ๆ (Unix เองก็เป็นมุก — มันล้อ Multics)

หัวใจของ Plan 9 — "ทุกอย่างคือไฟล์" จริง ๆ

จาก Unix สู่ Plan 9 — ทำให้สุดทาง

Unix มีแนวคิด famous: "everything is a file"

filesystem เป็นไฟล์ → /home/user/document.txt
devices เป็นไฟล์ → /dev/sda, /dev/tty
processes เป็นไฟล์ → /proc/1234

แต่มันมีข้อยกเว้น — network sockets, graphics, window system — สิ่งเหล่านี้ไม่ใช่ไฟล์ใน Unix

Plan 9 เอาแนวคิดนี้ไป สุดทาง — ใน Plan 9, ทุกอย่างคือไฟล์ ไม่มีข้อยกเว้น

9P — โปรโตคอลเดียวที่เชื่อมทุกอย่าง

หัวใจของ Plan 9 คือ 9P — โปรโตคอลที่ทำให้ทุกอย่างสื่อสารกันผ่าน filesystem

หน้าต่าง GUI → mount เป็นไฟล์
network connection → mount เป็นไฟล์  
เครื่องอื่นใน network → mount เป็นไฟล์

ลองนึกภาพ: คุณ ls ดูไฟล์ในเครื่องคนอื่นได้เหมือนกับเป็น local disk — โดยไม่ต้องใช้ NFS, Samba, หรืออะไรซับซ้อนเลย

ตัวอย่างจริง: ถ้าผมเปิดหน้าต่าง editor (acme) ใน Plan 9 — หน้าต่างนั้นคือไฟล์ใน /mnt/acme/ คุณสามารถ echo "hello" > /mnt/acme/body แล้วข้อความก็จะไปโผล่ใน editor ทันที

GUI ของ Plan 9 ไม่ใช่ "โปรแกรมที่วาดรูปบนจอ" — มันคือ "filesystem ที่บังเอิญแสดงผลเป็นกราฟิกได้"

Namespace — มุมมองส่วนตัวของทุก process

ใน Linux, ทุก process มองเห็น filesystem เดียวกัน

ใน Plan 9, แต่ละ process มี namespace ของตัวเอง — คุณสามารถ mount, unmount, และจัดเรียง filesystem ใหม่ได้โดยไม่กระทบ process อื่น

Process A: /bin → /usr/local/bin
Process B: /bin → /remote/machine/bin

สอง process นี้เห็น filesystem คนละชุด — แต่รันอยู่บนเครื่องเดียวกัน

แนวคิดนี้คือต้นกำเนิดของ Linux namespaces ที่ใช้ใน Docker และ container ทุกวันนี้

ชีวิตใน Plan 9 — หน้าตาเป็นยังไง

Rio — หน้าต่างที่ไม่มี title bar

Rio คือ window system ของ Plan 9 — และมัน minimal สุด ๆ

ไม่มี taskbar, ไม่มี desktop icons, ไม่มี minimize button — มีแต่หน้าต่างที่คุณจัดการด้วยเมาส์ 3 ปุ่ม

ปุ่มซ้าย = เลือกข้อความ
ปุ่มกลาง = execute (รันข้อความที่เลือก)
ปุ่มขวา = เมนู (New, Resize, Delete ฯลฯ)

ลองนึกภาพการใช้งานจริง:

คุณเปิดหน้าต่าง terminal ขึ้นมา — พิมพ์ ls -la — ผลลัพธ์โผล่ในหน้าต่าง คุณใช้ปุ่มซ้ายลากเลือกชื่อไฟล์ที่สนใจ → กดปุ่มกลาง → Plan 9 เอาไฟล์นั้นมาเป็น argument ให้คำสั่งถัดไปโดยอัตโนมัติ

หรือใน editor: คุณพิมพ์ man 9p ใน buffer → ลากคลุม → ปุ่มกลาง → หน้าต่าง man page โผล่ขึ้นมาทันที

ไอเดียคือ: คุณไม่ต้อง copy-paste — คุณแค่เลือกแล้ว execute ทุกอย่างที่เลือกคือ command ได้หมด

นี่คือ UX ที่ต่างจากสิ่งที่เราใช้ทุกวันนี้โดยสิ้นเชิง — ไม่มี clipboard, ไม่มี Ctrl-C/Ctrl-V — แต่เมื่อคุณชินแล้ว มันเร็วและ natural กว่ามาก

Acme — editor ที่เป็นมากกว่า editor

Acme คือ text editor ในตำนานที่ Rob Pike สร้าง — และมันก็คือ "หน้าต่างที่ควบคุมด้วยเมาส์แบบ hypertext"

ทุกคำใน Acme เป็น clickable link
คุณพิมพ์คำสั่ง shell ลงไปใน buffer แล้วคลิก execute ได้เลย
ไฟล์ทุกไฟล์ที่เปิดอยู่คือหน้าต่างที่จัดการได้ด้วย mouse gesture

Acme ดู primitive สำหรับยุคนี้ — แต่มันคือต้นแบบของ IDE สมัยใหม่: code + terminal + file browser อยู่ในหน้าต่างเดียวกัน

Plumbing — messsage bus ก่อนจะมี D-Bus

Plumbing คือระบบส่งข้อความระหว่างโปรแกรมใน Plan 9

คุณ click ที่ URL → มันส่งไปให้ browser
คุณ click ที่ error message → มันเปิดไฟล์ไปที่บรรทัดนั้น

ทุกอย่างเชื่อมกันด้วยไฟล์ — และ plumbing ก็คือไฟล์พิเศษที่อ่านเขียนข้อความได้

มรดกของ Plan 9 — สิ่งที่อยู่รอดมาจนถึงวันนี้

1. UTF-8 — เกิดบนกระดาษรองจานในร้านอาหารแห่งหนึ่ง

คืนหนึ่งในปี 1992 — Ken Thompson กับ Rob Pike นั่งกินข้าวที่ร้านอาหารสไตล์ diner แห่งหนึ่งใน New Jersey

พวกเขาคุยกันเรื่องปัญหาที่โลกคอมพิวเตอร์มี encoding เป็นร้อย ๆ แบบ — ASCII, Latin-1, Shift-JIS — แต่ละตัวใช้กับภาษาเดียว

ทั้งคู่หยิบกระดาษรองจานขึ้นมา แล้วออกแบบ UTF-8 — encoding ที่ backward compatible กับ ASCII และรองรับทุกภาษาในโลก

วันนี้ UTF-8 ใช้ใน 98% ของเว็บทั้งโลก

และมันถูกออกแบบระหว่างการพัฒนา Plan 9 — โดยคนของ Plan 9

2. `/proc` filesystem — เกิดใน Unix แต่ Plan 9 ทำให้มันเป็นอย่างที่เราใช้

Linux users รู้จัก /proc — filesystem ที่เก็บข้อมูล process:

cat /proc/cpuinfo    # ดู CPU
cat /proc/meminfo    # ดูหน่วยความจำ

/proc เกิดครั้งแรกใน Unix รุ่น 8 (1984) โดย Tom Killian — ผู้เขียน paper "Processes as Files" ที่นำเสนอใน USENIX เดือนมิถุนายน 1984 ซึ่งเกิดก่อน Plan 9 จะเริ่มพัฒนาด้วยซ้ำ

แต่ /proc ใน Unix 8 เป็นแบบ flat — หนึ่ง process = หนึ่งไฟล์

Plan 9 คือคนที่พัฒนาแนวคิดนี้ต่อไป — ทำให้แต่ละ process เป็น directory ที่มีหลายไฟล์ย่อย (ใช้ ls ดู, cat อ่านค่าต่าง ๆ ได้) — กลายเป็น hierarchical /proc แบบที่เราใช้กันทุกวันนี้

Linux สืบทอด hierarchical model นี้มาจาก Plan 9 — และทุกวันนี้ /proc กลายเป็นมาตรฐาน

3. Linux Namespaces — Container ทั้งหมดมีรากจาก Plan 9

Docker, Kubernetes, container ทั้งหมด — ใช้ Linux namespaces ในการแยก process

แนวคิด "แต่ละ process มีมุมมองของระบบที่แตกต่างกัน" — เกิดใน Plan 9

พูดให้เห็นภาพ: Plan 9 คิดเรื่อง per-process namespace ตั้งแต่ปลายยุค 80 — ส่วน Linux namespaces ที่เป็นรากฐานของ Docker และ container ทั้งหมด เพิ่งมาใน kernel ราวปี 2008 หรือเกือบ 20 ปีให้หลัง

4. Go — ภาษาโปรแกรมที่สืบทอด DNA จาก Plan 9

Go ถูกสร้างโดย Rob Pike, Ken Thompson, และ Robert Griesemer — สามคนที่เคยทำงานบน Plan 9

และ Go ก็เต็มไปด้วยแนวคิดจาก Plan 9:

Goroutines — lightweight threads → ต้นแบบคือ lightweight processes ของ Plan 9
Channels — สื่อสารด้วยการส่งข้อความ → ต้นแบบคือ 9P และ plumbing
Gofmt — ทุกคนเขียนโค้ดหน้าตาเหมือนกัน → ต้นแบบคือ philosophy "หนึ่งวิธีที่ดีที่สุด" ของ Plan 9
Static binary — compile เป็นไฟล์เดียว → ต้นแบบคือ Plan 9 binaries

Go คือ Plan 9 ในร่างของภาษาโปรแกรม

ทำไม Plan 9 ถึงไม่รุ่ง

ปัญหาที่แก้ไม่ได้

Chicken-and-egg problem — ไม่มี applications เพราะไม่มี users → ไม่มี users เพราะไม่มี applications
Licensing — ยุค 90 Bell Labs ถูกขายต่อหลายมือ (AT&T → Lucent → ...) ทำให้ license ของ Plan 9 ซับซ้อน
Linux ชนะไปแล้ว — ตอน Plan 9 เริ่ม stable (กลางยุค 90), Linux กำลังโตเร็วและมี ecosystem ใหญ่กว่า
Hardware support — Plan 9 รองรับ hardware น้อยมาก เทียบกับ Linux/Windows

แต่ปัญหาหลักคือ: Plan 9 ไม่ได้พยายามจะ "ดีกว่า Unix นิดหน่อย" — มันพยายามจะ "ใหม่หมด"

และโลกไม่พร้อมจะเปลี่ยน OS ทั้งระบบเพื่อไอเดียใหม่ ๆ — ถึงแม้ไอเดียเหล่านั้นจะดีกว่า

Plan 9 ในปี 2026

Plan 9 ยังมีชีวิตอยู่ — ในรูปแบบของ 9front (community fork) และ Plan 9 from User Space (port ของ tools บน Linux/macOS)

มีกลุ่ม enthusiasts ที่ใช้ Plan 9 เป็น daily driver — เล็ก แต่บ้าพลัง

และทุก concept ที่ Plan 9 เคยคิด — ถูก implement ใหม่ใน Linux ในอีก 20 ปีต่อมา

สิ่งที่ Plan 9 สอนเรา

"แนวคิดที่ดีไม่ได้แปลว่าจะชนะ — แต่มันจะถูกขโมย"

Plan 9 ล้มเหลวในฐานะผลิตภัณฑ์ — แต่ชนะในฐานะแนวคิด

ทุก container ที่รันอยู่บน Kubernetes...
ทุก UTF-8 byte ที่ส่งผ่าน network...
ทุก Go routine ที่ทำงานอยู่บน cloud...

ทั้งหมดมี DNA ของ Plan 9 อยู่ในนั้น

ที่มา: Bell Labs Technical Journal, Plan 9 manual pages, Rob Pike's personal blog (herpolhode.com), 9fans.net, Wikipedia

Russ Cox — คนที่ทำให้ Go เป็น ecosystem ไม่ใช่แค่ภาษา

Gophernment — Fri, 31 Jul 2026 03:09:23 +0000

📅 กรกฎาคม 2026
⚠️ อ้างอิงจากแหล่งปฐมภูมิ ตรวจสอบแล้ว — แต่เช็คข้อมูลล่าสุดก่อนแชร์

ถ้า Pike, Thompson, และ Griesemer คือคนสร้าง Go

Russ Cox คือคนที่ทำให้ Go โตจากภาษาใน Google เป็น ecosystem ที่คนทั้งโลกใช้ เขาเป็นคนเขียน gofmt คนออกแบบ Go modules คนคิด Minimal Version Selection algorithm คนเขียน compatibility promise และปัจจุบันเป็น Go tech lead — คนที่ตัดสินใจว่า Go จะไปทางไหนต่อ

ทุกครั้งที่คุณพิมพ์ go build แล้วมันทำงานในไม่กี่วินาที นั่นคือ Cox

เด็ก Plan 9 จาก MIT

ตอนที่เพื่อนวัยเดียวกันใช้ Windows หรือ Mac Russ Cox ใช้ Plan 9 — ระบบปฏิบัติการที่ Rob Pike, Ken Thompson, และ Dennis Ritchie สร้างที่ Bell Labs

เขาใช้มันเป็นระบบปฏิบัติการหลักทุกวัน

ตอนเรียน MIT Cox ทำงานกับ Pike โดยตรงในโปรเจกต์ Plan 9 ร่วมเขียน paper "Security in Plan 9" (USENIX 2002) ทั้งที่ยังเป็นนักศึกษา

แต่พอเว็บเริ่มสำคัญ Plan 9 ไม่มีเว็บเบราว์เซอร์ที่ใช้งานได้

แทนที่จะย้ายไปใช้ OS อื่น Cox ทำสิ่งที่ programmer ดี ๆ จะทำ: port Plan 9 ทั้งระบบมาที่ Unix

plan9port คือ Plan 9 userspace ที่รันบน Linux และ macOS คุณสามารถใช้ acme editor, sam editor, rc shell, plumber — เครื่องมือทั้งหมดของ Plan 9 — บนเครื่องธรรมดา

Cox ใช้ Acme เป็น editor หลักทุกวัน มาจนถึงทุกวันนี้

นี่คือจุดที่ Pike สังเกตเห็นเขา "เด็กคนนี้เข้าใจ Plan 9 ดีพอที่จะ port มันมาทั้งระบบ"

Google Code Search และ RE2

Cox ฝึกงานที่ Google ระหว่างเรียนปริญญาเอกที่ MIT

งานที่ทำให้เขาเป็นที่รู้จักคือ RE2 — regular expression engine ที่เขาเขียนให้ Google Code Search

ปัญหาของ regex engine ทั่วไปคือ catastrophic backtracking: บาง pattern ใช้เวลาค้นหาเป็นนาที, ชั่วโมง, หรือพังเลย เพราะ algorithm แบบ backtracking มี worst-case ที่ exponential

Cox ใช้ automata theory จากงานวิจัยของเขา ออกแบบ RE2 ที่การันตี linear time เสมอ ไม่ว่า pattern จะซับซ้อนแค่ไหน

RE2 ถูกใช้ใน production ที่ Google ตั้งแต่ปี 2006 — Google Code Search, Google Sheets, และต่อมาเป็น regexp package ใน Go standard library

เขาเขียนบทความสามตอนที่กลายเป็น reference ของวงการ regex: "Regular Expression Matching Can Be Simple And Fast", "Regular Expression Matching: the Virtual Machine Approach", "Regular Expression Matching in the Wild"

2008 — Pike ชวนเข้าร่วมทีม Go

Cox กำลังจะจบปริญญาเอกที่ MIT (วิทยานิพนธ์ "An Extension-Oriented Compiler") ตอนที่ Pike มาชวน

Pike พูดว่า: "เราพยายามเอาทุกอย่างที่เรารักเกี่ยวกับการพัฒนา software บน Plan 9 มาทำให้มันใช้ได้กับการเขียน software ที่เราอยากเขียนที่ Google นายอยากช่วยไหม"

Cox ตอบ: "Yeah, of course"

เขากลายเป็น member คนที่ 4 ของทีม Go — ต่อจาก Pike, Thompson, Griesemer

gofmt — โปรเจกต์แรก

งานแรกของ Cox ในทีม Go คือ gofmt

ธันวาคม 2009 เขาเขียน blog post ประกาศ gofmt — เครื่องมือที่ format โค้ด Go ให้หน้าตาเหมือนกันหมดโดยอัตโนมัติ

ฟังดูเป็นเรื่องเล็ก แต่ gofmt คือหนึ่งในการตัดสินใจที่ฉลาดที่สุดในประวัติศาสตร์ Go

ก่อน gofmt ทีม Go เสียเวลาเถียงกันเรื่อง style ว่า bracket ควรอยู่บรรทัดเดียวกับ if หรือบรรทัดใหม่ indent ควรเป็น tab หรือ space ควรเว้นวรรคหลัง comma ไหม

หลัง gofmt ปัญหานี้หายไปตลอดกาล

ทุกวันนี้ทุกโปรเจกต์ Go ในโลกหน้าตาเหมือนกัน ไม่ว่าคุณจะอ่านโค้ดของ Google, ของ startup, หรือของ open source contributor

`go` command — คุณใช้มันทุกวันโดยไม่เคยคิดถึงมัน

Cox เป็นคนออกแบบ go command — go build, go test, go get — ทั้งหมดที่คุณพิมพ์ทุกวัน

แต่ผลงานที่เปลี่ยน Go ไปตลอดกาลคือ Go modules

Go Modules — จุดเปลี่ยนของ Go ecosystem

ก่อน Go 1.11 การจัดการ dependency ใน Go คือหายนะ

go get ดึงโค้ดจาก version control โดยตรง ไม่มี versioning ไม่มี lock file Dependency ของโปรเจกต์หนึ่งอาจ silently upgrade แล้วพังโปรเจกต์อีกโปรเจกต์

กุมภาพันธ์ 2018 Cox เปิดตัว vgo — prototype ของ Go modules ที่เขาเขียนคนเดียว

แล้วเขาก็ทำสิ่งที่แทบไม่มีใครทำ: เขียน blog post 10 ตอนอธิบายการตัดสินใจทุกอย่าง

ทำไมต้อง semantic import versioning
Minimal Version Selection คืออะไร และทำไมมันดีกว่า SAT solving แบบ npm
reproducible builds ทำงานยังไง
หลักการของ versioning ใน Go

Minimal Version Selection (MVS) เป็น algorithm ที่ Cox คิดขึ้นมาเอง แทนที่จะพยายามหา "best possible combination" ของ dependency versions แบบ npm (ซึ่งใช้ SAT solver และใช้เวลานานมาก) MVS เลือก version ต่ำสุดที่ satisfy requirement ของทุก module

ผลลัพธ์: go mod tidy ทำงานใน 2 วินาที แทนที่จะ resolve dependency tree เป็นนาที

Go modules กลายเป็นมาตรฐานใน Go 1.13 และเป็น default ใน Go 1.16

Go Compatibility Promise — โค้ด 10 ปี compile ได้

สิงหาคม 2023 Cox เขียน blog post "Backward Compatibility, Go 1.21, and Go 2"

ประโยคเปิดของ post นั้นกลายเป็นคำขวัญของ Go:

"Boring is good. Boring is stable. Boring means being able to focus on your work, not on what's different about Go."

Cox เป็นคน maintain compatibility promise ของ Go review ทุก change ที่อาจ break backward compatibility

ลองนึกถึงภาษาอื่นที่โค้ดปี 2012 ไม่สามารถ compile ด้วย compiler ปี 2026 ได้โดยไม่ต้องแก้

Go ทำได้ เพราะ Cox และทีมทุ่มเทให้ compatibility เป็นพระเจ้า

Transparent Decision-Making

สิ่งที่ Cox เปลี่ยนวิธีทำงานของทีม Go ไม่ใช่แค่โค้ด แต่คือ กระบวนการ

เขาเป็นคนออกแบบ Go proposal process — ทุกการเปลี่ยนแปลงใหญ่ต้องผ่าน proposal สาธารณะบน GitHub พร้อม design doc ที่อธิบายปัญหา, ทางเลือก, และเหตุผล

เขาเขียน blog post 6 ตอนอธิบายกระบวนการนี้: "Clarity & Transparency", "Large Changes", "Scaling Discussions" "Enabling Experiments", "Representation"

ไม่มี "คนเก่งที่สุดในห้องตัดสินใจ" ทุกการตัดสินใจของ Go ตั้งแต่ Go 1.0 ถึงวันนี้ถูกบันทึกไว้เป็นลายลักษณ์อักษร

นี่คือสิ่งที่ Cox เรียกว่า "language design in the service of software engineering" — การออกแบบภาษาไม่ใช่ศิลปะของอัจฉริยะ แต่เป็นวิศวกรรมที่มีกระบวนการ มีเหตุผล มีบันทึก

ปรัชญา

GitHub bio ของ Cox เขียนว่า: "Go Hacker. Mistake maker."

เขาไม่เคยแกล้งทำเป็นรู้ทุกอย่าง และนั่นคือสิ่งที่น่านับถือที่สุด

ตอนให้สัมภาษณ์ GoTime ปี 2018 เขาพูดถึงความคาดหวังตอนแรก:

"My hope was that maybe a few people would notice, and ideally whatever the next big language to come along would steal the concurrency and the interface ideas from Go, and that would be our tiny little contribution to making programming a little bit better. Obviously, that didn't happen, but I'm okay with how it turned out instead."

"หวังว่าไม่กี่คนจะสังเกตเห็น" — แล้ว Go ก็กลายเป็นภาษาที่ใช้ใน production ทั่วโลก

อีกด้านของ Cox — นักคณิตศาสตร์

Cox ไม่ใช่แค่วิศวกร Go

เขาเป็น President ของ OEIS Foundation (Online Encyclopedia of Integer Sequences) — ฐานข้อมูลลำดับจำนวนเต็มที่ใหญ่ที่สุดในโลก นักคณิตศาสตร์และนักวิทยาศาสตร์คอมพิวเตอร์ใช้ OEIS เป็น reference มาตั้งแต่ปี 1964

ผลงานล่าสุดบน blog ของเขา (2024-2026) ส่วนใหญ่เป็นเรื่อง floating-point formatting — ลงลึกถึงระดับ "Pull a New Proof from Knuth's Fixed-Point Printer" และ "Fast Unrounded Scaling: Proof by Ivy"

เขาใช้ Ivy ภาษา calculator แนว APL ที่ Rob Pike เขียน พิสูจน์ความถูกต้องของ algorithm เชิงคณิตศาสตร์

นี่คือคนที่วันหนึ่งออกแบบ Go modules, อีกวันใช้ formal proof พิสูจน์ว่า floating-point formatter ทำงานถูกต้อง

ผลงานอื่น ๆ

ก่อน Go, Cox มีผลงานอีกมาก:

Vx32 sandboxing system (USENIX 2008)
Vivaldi network coordinate system (SIGCOMM 2004) — ใช้หา latency ระหว่าง node ใน distributed system โดยไม่ต้องวัดทุกคู่
Xoc extensible compiler (ASPLOS 2008)

หลัง Go:

Go Memory Model — เขียนบทความอธิบาย memory model ของ Go และ hardware memory models (2021-2022)
Transparent Telemetry — ระบบเก็บข้อมูลการใช้งาน Go toolchain แบบโปร่งใส (2022)
Coroutines for Go — proposal สำหรับ coroutine ใน Go (กรกฎาคม 2023)
xz backdoor analysis — วิเคราะห์ timeline ของ backdoor ใน xz library (2024)

ทุกวันนี้

Cox ยังเป็น Go tech lead ทำงานที่ Google Cambridge, MA ใช้ Acme editor ทุกวัน

เขียน blog ที่ research.swtch.com อย่างสม่ำเสมอ 150+ บทความและยังเพิ่มขึ้นเรื่อย ๆ

2024-2026: เขียนเรื่อง Go Changes, Go Testing By Example, floating-point formatting series, hash-based bisect debugging, differential coverage

เขาไม่ได้เป็น keynote speaker ที่มีคนดูเป็นหมื่น แต่ทุกครั้งที่เขาเขียนอะไร คนในทีม Go และ community อ่าน

Cox กับโปรแกรมเมอร์ไทย

go mod tidy ที่ทำงานใน 2 วินาที คือ Cox

gofmt ที่ทำให้โค้ดทุกโปรเจกต์หน้าตาเหมือนกัน คือ Cox

Compatibility promise ที่ทำให้โค้ด Go ปี 2012 ยัง compile ได้ในปี 2026 คือ Cox

และวัฒนธรรม "ตัดสินใจแบบโปร่งใส เขียนเหตุผลให้อ่านได้" ที่กลายเป็น DNA ของ Go community

คือสิ่งที่ Cox สร้าง

สรุป

Rob Pike, Ken Thompson, Robert Griesemer คือคนสร้าง Go

แต่ Russ Cox คือคนที่ทำให้มันอยู่รอด

ที่มา: swtch.com/~rsc, research.swtch.com, go.dev/blog, GoTime #77, github.com/rsc, github.com/google/re2, pdos.csail.mit.edu/~rsc

Robert Griesemer — ศิษย์ของ Wirth ผู้เขียน spec ให้ Go และทำให้ generics เป็นจริง

Gophernment — Fri, 31 Jul 2026 03:06:38 +0000

📅 กรกฎาคม 2026
⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน — API และเวอร์ชันอาจเปลี่ยนแปลงภายหลัง

เวลาพูดถึงคนสร้าง Go ทุกคนรู้จัก Rob Pike กับ Ken Thompson

แต่คนที่สามบน whiteboard วันนั้น คนที่เขียน Go specification คนที่ออกแบบ type inference algorithm ให้ Go คนที่ผลักดัน generics ตั้งแต่ proposal จนถึง implementation

เขาไม่ใช่คนที่คุณเห็นบนเวทีบ่อย ๆ ไม่มี Twitter ไม่ใช่หน้าเป็นข่าว

Robert Griesemer

ศิษย์ของ Niklaus Wirth

Griesemer เกิดปี 1964 ที่สวิตเซอร์แลนด์ จบปริญญาเอกจาก ETH Zurich หนึ่งในมหาวิทยาลัยวิศวกรรมที่ดีที่สุดในยุโรป

อาจารย์ที่ปรึกษาของเขาคือ Hanspeter Mössenböck ภายใต้การดูแลของ Niklaus Wirth — ผู้สร้างภาษา Pascal, Modula, และ Oberon

ถ้าคุณเคยเขียน Pascal ตอนเรียนมหาวิทยาลัย คุณใช้ภาษาที่ Wirth ออกแบบ Wirth ได้รับ Turing Award ปี 1984 จากผลงานการออกแบบภาษาโปรแกรมมิ่งทั้งตระกูล

Griesemer เติบโตมาในโรงเรียนแห่งนี้ วิทยานิพนธ์ปริญญาเอกของเขาชื่อ "A programming language for vector computers" (1993) เน้นการออกแบบภาษาให้กับฮาร์ดแวร์เฉพาะทาง

และร่องรอยของ Wirth อยู่ใน Go จนถึงทุกวันนี้ Go specification ใช้ Wirth Syntax Notation (EBNF variant) ซึ่งเป็น notation ที่ Wirth คิดค้นขึ้นมา นี่ไม่ใช่เรื่องบังเอิญ

ก่อน Go: จาก HotSpot สู่ V8

ก่อนจะมาเป็นหนึ่งในสามคนสร้าง Go Griesemer มีผลงานที่โลกใช้กันทุกวัน

Object Oberon ขยายภาษา Oberon ของ Wirth ให้มี object-oriented features นี่คือจุดเริ่มต้นของความคิดเรื่อง type system ที่ต่อมาทำให้ Go แตกต่างจากภาษา C-family ทั่วไป

Java HotSpot VM Griesemer ร่วมเขียน compiler ให้ HotSpot ซึ่งเป็น JVM implementation ที่ทำให้ Java เร็วพอสำหรับ enterprise และรันอยู่ในเซิร์ฟเวอร์เป็นล้านเครื่องทั่วโลก

V8 JavaScript engine เขาเป็นหนึ่งในทีมแรก ๆ ของ V8 ที่ Google engine ตัวนี้ทำให้ Chrome เร็วขึ้นหลายเท่า ทำให้ Node.js เกิด และเปลี่ยน JavaScript จากภาษาที่คนดูถูกว่า "ช้า" เป็นภาษาที่เร็วพอจะรัน server-side ได้

Sawzall ภาษา data processing ของ Google ที่ Griesemer ทำร่วมกับ Pike และทีม Google อีกหลายคน เป็นประสบการณ์ที่ทำให้เขาเห็นว่า "ภาษาสำหรับงานเฉพาะทาง" ควรหน้าตาเป็นยังไง

Paxos Made Live (2006) paper ที่อธิบายความท้าทายในการ implement Paxos algorithm ในระบบ production แสดงให้เห็นว่า Griesemer ไม่ใช่แค่นักทฤษฎีภาษา แต่ยังเข้าใจ distributed systems engineering ด้วย

21 กันยายน 2007 — วันที่สามคนยืนหน้า whiteboard

Go FAQ บันทึกวันที่นี้ไว้อย่างชัดเจน:

"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007."

สามคนนี้มาจากคนละโลก Pike คือ systems programmer จาก Bell Labs Thompson คือตำนาน Unix ทีสร้างภาษา B และร่วมสร้าง UTF-8 ส่วน Griesemer มาจากโลกของ type theory, formal semantics, และ compiler design

นี่คือสิ่งที่ทำให้ทีมนี้สมบูรณ์ Pike กับ Thompson คิดจากมุม developer experience ส่วน Griesemer คิดจากมุม "ภาษาแบบนี้ type system ควรเป็นยังไง"

และผลลัพธ์ที่จับต้องได้ที่สุดจากมุมของ Griesemer คือ Go specification

Go Spec — มหากาพย์เงียบ

Go language specification คือเอกสารที่ programmer Go ทุกคนเปิดอ่านตอนสงสัยว่า syntax แบบนี้ถูกต้องไหม ภาษาเวอร์ชันนี้เปลี่ยนอะไรไปจากเวอร์ชันก่อน

Griesemer เป็น primary author ของ spec นี้

การเขียน spec ไม่ใช่งานที่มีคนปรบมือให้ แต่คือสิ่งที่ทำให้ Go เป็นภาษาที่ compiler ทุกตัว (gc, gccgo, TinyGo) ทำงานตรงกัน เพราะทุกอย่างถูกนิยามไว้ชัดเจน ไม่มี "มันควรจะทำงานแบบนี้แหละ" หรือ "แล้วแต่ implementation"

spec ใช้ Wirth Syntax Notation ภาษาที่อาจารย์ของ Griesemer คิดค้นขึ้นเมื่อ 40 ปีก่อน นั่งอยู่ในเอกสารภาษาใหม่ที่รันอยู่ใน production เป็นล้านเครื่องทั่วโลก

Type Inference — สิ่งที่ทำให้ Go generics ใช้งานได้จริง

นี่คือผลงานที่แสดง DNA ของ Griesemer ชัดที่สุด

Go มี type inference ตั้งแต่แรก (:=) แต่ของที่ยากคือ type inference สำหรับ generics ที่เขาออกแบบให้กับ Go 1.18

Griesemer เป็นคนออกแบบ type unification algorithm ที่ทำให้คุณเขียน slices.Sort(list) แทนที่จะต้องเขียน slices.Sort[MyType](list) ได้

เขายังเป็นคนเขียน blog post บน go.dev (ตุลาคม 2023) อธิบายการทำงานของ type inference อย่างละเอียด ตั้งแต่หลักการจนถึง edge case

ประโยคหนึ่งใน post นั้นสรุปปรัชญาของเขาได้ดี:

"Type inference is an optional mechanism: if type arguments make code clearer, by all means, write them down."

ไม่ใช่ "type inference จะเดาทุกอย่างให้คุณ" แต่คือ "type inference จะช่วยคุณในที่ที่มันแน่ใจ และให้คุณควบคุมในที่ที่มันไม่แน่ใจ"

นี่คือ pragmatic language design — ให้เครื่องมือกับ programmer แต่ไม่บังคับ

Generics — 10 ปีที่ทำให้มันถูกต้อง

Generics ใน Go ใช้เวลา design นานกว่าทศวรรษ ไม่ใช่เพราะ Go team ขี้เกียจ แต่เพราะพวกเขาไม่ยอมปล่อยอะไรที่ "เกือบดี"

Griesemer กับ Ian Lance Taylor เป็นสองคนหลักที่เขียน proposal "The Next Step for Generics" (มิถุนายน 2020)

เขาเป็นคนออกแบบ:

Type inference algorithm
Interface-based constraint system
~ (approximation) syntax สำหรับ type constraints
Square brackets [] สำหรับ type parameters (การเลือกที่ถกเถียงกันมาก แต่เขายืนยันว่าดีกว่า <> เพราะไม่ชนกับ comparison operators)

ทุกครั้งที่คุณเขียน func Sort[T cmp.Ordered](list []T) คุณกำลังใช้ type system ที่ Griesemer ออกแบบ

ปรัชญาการทำงาน

คนที่เคยร่วมงานกับ Griesemer บอกตรงกัน: เขาเป็นคนเงียบ ถามทีตอบที comment ใน code review เฉียบและสั้น

Go spec ทุกเวอร์ชันคือลายเซ็นของเขา ไม่มีน้ำ ไม่มี buzzword แต่เป๊ะ

มีคนเล่าว่าในทีม Go ถ้า spec บอกว่า "implementation-defined" Griesemer จะถามทันทีว่าทำไม แล้วช่วย redesign จนมันไม่ต้องเป็น undefined อีก

นี่คือ DNA ที่มาจาก Wirth: ทำให้ทุกอย่าง explicit ใน spec ทำให้ compiler implement ได้ตรงกันทุกตัว

การปรากฏตัวต่อสาธารณะ

Griesemer ไม่ใช่คนที่คุณเห็นบ่อยบนเวที conference แต่ก็ไม่ใช่ว่าไม่เคยขึ้นเลย

เขาพูดที่ GopherCon SG 2017 (keynote: "Exporting Go"), GopherCon 2016, dotGo 2016, Gopherpalooza 2019, GopherCon 2020, GopherCon 2021 (ร่วมกับ Ian Lance Taylor), และ GopherCon 2023

นอกจากนี้ยังเคยให้สัมภาษณ์ใน GoTime podcast

แต่เมื่อเทียบกับ Pike ที่มีบล็อก 150+ บทความและเป็น keynote speaker ระดับโลก หรือ Thompson ที่ได้ Turing Award

Griesemer เลือกที่จะให้งานพูดแทนตัวเขา

Blog post บน go.dev ที่ Griesemer เขียนเองมีไม่กี่ครั้ง: "The Next Step for Generics" (2020) และ "Type Inference" (2023)

แต่ทุกครั้งที่มีคนเปิด Go spec ทุกครั้งที่มีคนใช้ generics ทุกครั้งที่ type inference เดา type ได้ถูกต้องโดยที่คุณไม่ต้องประกาศ

นั่นคือลายเซ็นของเขา

ทุกวันนี้

Griesemer ยังทำงานที่ Google เป็นหนึ่งใน maintainer หลักของ Go

เขาไม่ใช่ "อดีตผู้สร้าง Go" เขาคือ "คนที่ยังสร้าง Go อยู่ทุกวันนี้"

Griesemer กับโปรแกรมเมอร์ไทย

Go spec ที่เขาเขียน คือเหตุผลที่คุณอ่าน type error แล้วไม่ต้องเดาว่ามันแปลว่าอะไร

Go generics ที่เขาออกแบบ คือเหตุผลที่คุณไม่ต้องเขียน interface{} แล้ว type-assert ไปมา

และปรัชญาที่เขาสืบทอดมาจาก Wirth "ทำให้ของซับซ้อนง่ายด้วย specification ที่ดี" คือสิ่งที่โปรแกรมเมอร์ไทยทุกคนได้ประโยชน์ ไม่ว่าเราจะรู้ชื่อเขาหรือไม่

สรุป

Robert Griesemer คือ proof ว่าคุณไม่จำเป็นต้องดังเท่า Pike หรือ Thompson ถึงจะเปลี่ยนโลก

คุณแค่ต้องเขียน spec ให้ดีพอ

ที่มา: Go FAQ (go.dev), Wikipedia, Go blog (go.dev/blog), Go spec (go.dev/ref/spec), ETH Research Collection (research-collection.ethz.ch), Google Research (research.google/people/author96/), GoTime podcast, Griesemer's Type Inference post (Oct 2023)

Rob Pike — ผู้ชายที่เกลียดความซับซ้อน และสร้าง UTF-8 กับ Go

Gophernment — Thu, 30 Jul 2026 02:35:15 +0000

📅 กรกฎาคม 2026
⚠️ อ้างอิงจากแหล่งปฐมภูมิ ตรวจสอบแล้ว — แต่เช็คข้อมูลล่าสุดก่อนแชร์

ถ้าคุณพิมพ์ภาษาไทยแล้วไม่พัง
เขียน Go แล้วรู้สึกว่ามันง่ายเกินคาด
หรือสงสัยว่าทำไมภาษาใหม่ ๆ ถึงไม่มี inheritance

คุณกำลังใช้ของที่ผู้ชายคนหนึ่งใช้เวลา 40 ปีทำ

Rob Pike

เด็กเนิร์ดแคนาดา

Rob Pike เกิดปี 1956 โตมาในยุคที่คอมพิวเตอร์ยังเป็นเครื่องจักรขนาดห้อง

จบ BS จาก University of Toronto แล้วไปต่อที่ Caltech เขาสนใจ operating system กับ programming language ตั้งแต่วันแรก

ปี 1980 ได้งานที่ Bell Labs บ้านของ Unix, C และภาษาโปรแกรมมิ่งอีกนับไม่ถ้วน

ที่นั่นเขาได้ร่วมงานกับ Ken Thompson (ผู้สร้าง Unix) และ Dennis Ritchie (ผู้สร้าง C) สองคนที่วงการนี้เรียกว่าระดับเทพ

ยุค Bell Labs

สร้าง window system ตัวแรกของ Unix

ปี 1981 Pike เขียน window system ตัวแรกให้ Unix ก่อนที่โลกจะมี Windows หรือ Mac GUI ด้วยซ้ำ ต่อมาพัฒนาเป็น Blit terminal (1984) ที่มี overlapping windows

Plan 9 — OS ที่ล้ำเกินยุค

ทีม Pike, Thompson, Ritchie สร้าง Plan 9 ระบบปฏิบัติการที่เอาแนวคิด "ทุกอย่างคือไฟล์" ไปสุดทาง

ใน Unix พวก filesystem, network, devices ต่างก็เป็นไฟล์ แต่ยังมีข้อยกเว้น Plan 9 ทำแม้กระทั่งหน้าต่าง GUI ก็เป็นไฟล์ คุณ mount window ของคนอื่นมาดูผ่าน network ได้เลย

Plan 9 ล้ำมาก แต่ไม่เคยเป็น mainstream โลกไปทาง Windows กับ Linux แทน

แต่แนวคิดของ Plan 9 กลายเป็น DNA ของทุกอย่างที่ Pike ทำต่อมา

Inferno — Plan 9 เวอร์ชัน network

ต่อจาก Plan 9 พวกเขาสร้าง Inferno OS ที่ออกแบบให้รันบน network ตั้งแต่เกิด

มาพร้อมภาษา Limbo ที่หน้าตาเหมือน Go เวอร์ชันดั้งเดิม แต่ก่อน Limbo ก็ยังมี Newsqueak ภาษาที่ Pike เขียนตอนปี 1989 สำหรับ experiment เรื่อง concurrency โดยเฉพาะ

นี่คือจุดที่สำคัญ goroutine และ channel ที่เราใช้ใน Go ทุกวันนี้ มีต้นแบบตรง ๆ จาก Newsqueak (1989) → Alef (1992) → Limbo (1995) → Go (2009) สาย DNA นี้ตรงมาก คนเขียน Go ส่วนใหญ่ไม่รู้ว่า concurrency model ที่ตัวเองใช้ทุกวัน อายุเกือบ 40 ปีแล้ว

Inferno ก็เหมือน Plan 9 ล้ำเกินไปสำหรับยุคนั้น

UTF-8 — ของที่คุณใช้ทุกวันโดยไม่รู้ตัว

นี่คือหนึ่งใน origin story ที่ดีที่สุดของวงการคอมพิวเตอร์

กันยายน 1992 Pike ได้เมลจากคณะกรรมการ X/Open ให้ช่วยรีวิวข้อเสนอ encoding ใหม่ชื่อ FSS/UTF Pike ลิสต์สิ่งที่ encoding ที่ดีควรทำได้ แล้วพบว่า FSS/UTF ขาดไปอย่างน้อยหนึ่งข้อ

เย็นวันนั้น Pike กับ Ken Thompson ไปกินข้าวที่ร้านอาหารใน New Jersey Ken Thompson เป็นคนออกแบบ bit-packing ของ UTF-8 บนกระดาษรองจาน (placemat) Pike นั่งดูอยู่ตรงหน้า

คืนนั้นพวกเขาโทรกลับไปหา X/Open บอกว่าพร้อมจะ implement ให้เสร็จภายในวันจันทร์

วันศุกร์สัปดาห์เดียวกัน Plan 9 รันบน UTF-8 เต็มระบบ (บันทึกใน source code: 4 กันยายน 1992 เวลา 19:51:55)

หัวใจของ UTF-8 คือ backward compatibility กับ ASCII ตัวอักษร A-Z ยังใช้ 1 byte เหมือนเดิม แต่ภาษาไทย จีน ญี่ปุ่น เติมอีกไม่กี่ byte

วันนี้ UTF-8 ใช้กับเกือบ 98% ของเว็บทั้งโลก ทุกครั้งที่คุณส่งข้อความภาษาไทยแล้วไม่พัง คุณกำลังใช้ของที่ Thompson ออกแบบและ Pike นั่งดูอยู่ข้าง ๆ ในร้านอาหารเย็นนั้น

Pike เคยแก้ความเข้าใจผิดด้วยตัวเอง: "UTF-8 was designed, in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992" — ไม่ใช่ IBM เป็นคนออกแบบ

หนังสือ The Unix Programming Environment

ปี 1984 Pike เขียนหนังสือ "The Unix Programming Environment" ร่วมกับ Brian Kernighan (อีกหนึ่งตำนาน Bell Labs)

หนังสือเล่มนี้สอนปรัชญา Unix: เขียนโปรแกรมที่ทำอย่างเดียวแต่ทำให้ดี, ต่อท่อเชื่อมกัน, ใช้ text เป็น interface ปรัชญานี้กลายเป็นกระดูกสันหลังของ Go ในอีก 25 ปีต่อมา

Google และการเกิดของ Go

ที่มา: ตำนาน 45 นาทีที่เปลี่ยนทุกอย่าง

ปี 2002 Pike ย้ายไป Google

ตามตำนานที่ Pike เองเรียกว่า "origin myth" วันหนึ่งปี 2007 มี build ของ Google binary ใหญ่ตัวหนึ่งที่ใช้เวลานานมาก (คนเล่ากันว่า 45 นาที) Pike หันไปคุยกับ Robert Griesemer ระหว่างรอ Ken Thompson มาร่วมวง

21 กันยายน 2007 ทั้งสามคนเริ่มร่างภาษาใหม่บน whiteboard ในห้องประชุมของ Google

เป้าหมายชัด: compile เร็วแม้ codebase จะใหญ่แค่ไหน, ไม่มี inheritance ไม่มี exception, concurrency ในตัว (goroutine + channel สืบทอดมาจาก Newsqueak และ Limbo), และ garbage collection ที่ไม่ทำให้ช้า

Pike เสนอชื่อ "go" เพราะสั้น พิมพ์ง่าย

Go เปิดตัว

พฤศจิกายน 2009 Google open source Go

สิ่งที่ทำให้ Go ต่าง: มันไม่ใช่ academic language ไม่มี paper รองรับ ไม่มี type system ซับซ้อน มันคือภาษาของวิศวกรที่อยากทำงานให้เสร็จ

Compile เป็น static binary ไฟล์เดียว ไม่มี dependency hell และมี gofmt โค้ดทุกคนหน้าตาเหมือนกัน เลิกเถียงเรื่อง style ได้เลย

Go 1.0 ปล่อยมีนาคม 2012 และรักษา backward compatibility มาจนถึงทุกวันนี้

Go ชนะเพราะอะไร

Pike ออกแบบ Go ด้วยหลักการเดียวที่สรุปเป็นชื่อ talk ปี 2012 ของเขา: "Less is exponentially more."

ไม่ใช่แค่ทำน้อย ๆ แต่มันคือการตัดทุกอย่างที่ไม่จำเป็นออก จนเหลือแต่ของที่ต้องมีจริง ๆ

Go เลือกตัด inheritance (ใช้ composition + interface แทน), exception (ใช้ error return value), generic (ตอนแรก เพิ่มใน Go 1.18)

ทุกอย่างที่ Go ไม่มี คือสิ่งที่ Pike มองว่าเป็นภาระ ไม่ใช่ฟีเจอร์

ผลที่ได้: Go กลายเป็นภาษาเบอร์หนึ่งของ cloud infrastructure Docker, Kubernetes, Terraform, Prometheus ทั้งหมดเขียนด้วย Go

ปรัชญาของ Pike

Pike ไม่ใช่คนที่พูดเยอะ แต่ของที่พูดมักคม

"Less is exponentially more." หัวใจของ Go และทุกอย่างที่ Pike ทำ

"Object-oriented design is the roman numerals of computing." (2004) OOP คือเลขโรมันของวงการคอมพิวเตอร์ ใช้ได้แต่ไม่ควรเป็นค่า default

"Concurrency is not parallelism." ชื่อ talk ปี 2012 ที่กลายเป็นประโยคคลาสสิก concurrent ไม่ใช่ parallel

"A little copying is better than a little dependency." ก็อปโค้ดนิดหน่อย ดีกว่าเพิ่ม dependency ใหม่ทั้งตัว (Go proverb)

"Clear is better than clever." โค้ดที่ชัดเจน ดีกว่าโค้ดที่ฉลาด (Go proverb)

"Don't communicate by sharing memory; share memory by communicating." อย่าสื่อสารด้วยการแชร์ memory ให้แชร์ memory ด้วยการสื่อสาร หัวใจของ goroutine + channel

ทุกวันนี้

Pike ไม่ได้เกษียณ (ถึง Wikipedia จะพยายามเขียนแบบนั้นหลายรอบ แต่ไม่มีแหล่งอ้างอิง)

เขาเรียกตัวเองว่า "Professional dilettante" ยัง review Go code อยู่ ยังเขียนโค้ดใหม่ ๆ ลง GitHub เรื่อย ๆ

ผลงานล่าสุด: Ivy (เครื่องคิดเลขแนว APL), ภาษา Lisp ของตัวเอง, เครื่องมือภาษาญี่ปุ่น

2024 พูดที่ GopherConAU ในหัวข้อ "What We Got Right, What We Got Wrong" ยอมรับทั้งสิ่งที่ Go ทำถูก (spec, gofmt, compatibility, concurrency) และสิ่งที่พลาด (async/await ดีกว่า CSP? concurrency กับ parallelism อธิบายผิดมาตลอด?)

2025 โพสต์ "On Bloat" ชวนคิดว่า package เล็ก ๆ กลายเป็นปัญหาได้ยังไงเมื่อมี dependents เยอะ

มกราคม 2026 ลงลึกเรื่อง high-precision math ใน Ivy

ยัง active บน Mastodon และ Bluesky ใช้ชีวิตระหว่างสหรัฐฯ กับออสเตรเลียกับ Renée French ภรรยาที่เป็น illustrator และเป็นคนวาด Go gopher ที่เราเห็นกันทุกวันนี้

Pike กับโปรแกรมเมอร์ไทย

UTF-8 ทำให้ภาษาไทยอยู่บนเว็บได้โดยไม่พัง ก่อนหน้านั้น TIS-620 กับ Windows-874 ชนกันตลอด

Go เป็นภาษาที่บริษัทเทคไทยใช้กันเยอะขึ้น Agoda, LINE MAN Wongnai, SCB TechX ทั้งหมดมี Go ใน production

ปรัชญา "less is exponentially more" ของ Pike ยิ่งสำคัญในยุคที่ AI สร้างโค้ดได้เป็นล้านบรรทัด ทำน้อยแต่ดี ไม่ใช่ทำเยอะแล้วงง

สรุป

Rob Pike ใช้เวลา 40 ปีทำโจทย์เดียว: ทำยังไงให้คอมพิวเตอร์ง่ายสำหรับมนุษย์

UTF-8 ที่เราใช้ทุกวัน Go ที่รันบนเซิร์ฟเวอร์เป็นล้านเครื่อง ปรัชญา "less is exponentially more" ที่กลายเป็น DNA ของ developer รุ่นใหม่

ทั้งหมดเริ่มจากผู้ชายคนหนึ่งที่รอ C++ compile 45 นาที แล้วคิดว่า "เราทำได้ดีกว่านี้"

ที่มา: Wikipedia, go.dev, Rob Pike's blog (commandcenter.blogspot.com), UTF-8 history (Pike's own account 2003), Go FAQ, GitHub (github.com/robpike), Wikiquote

pkg.go.dev — มากกว่าแค่ที่อ่านเอกสาร Go

Gophernment — Sun, 19 Jul 2026 02:30:26 +0000

pkg.go.dev — มากกว่าแค่ที่อ่านเอกสาร Go

ถ้าคุณเขียน Go — คุณน่าจะเคยเปิด pkg.go.dev เพื่ออ่านเอกสาร package สักตัว

แต่ pkg.go.dev ไม่ใช่แค่ reader — มันคือ enforcement mechanism สำหรับ best practices ของระบบนิเวศ Go ทั้งหมด

ทุกครั้งที่มีคนเปิดหน้า package ของคุณ — pkg.go.dev จะแสดงผลการตรวจสอบ 4 อย่าง: มี go.mod ไหม, license เป็นอะไร, มี tagged version หรือเปล่า, version เสถียรหรือยัง

ถ้าคุณเขียน library แล้ว pkg.go.dev ไม่ขึ้นเครื่องหมายถูก — มันคือป้ายไฟนีออนที่บอกทุกคนว่า "package นี้ยังไม่พร้อมสำหรับ production"

4 เครื่องหมายที่ pkg.go.dev เช็ค

1. Has go.mod file

go.mod คือมาตรฐาน dependency management ของ Go — ตั้งแต่ Go 1.11 — และ pkg.go.dev ถือว่าการมี go.mod คือ baseline

ไม่มี go.mod → ไม่ใช่ Go module → ไม่มี versioning จริง → pkg.go.dev จะแสดง package แบบไม่มีข้อมูลเวอร์ชัน

สิ่งที่ควรทำ: ทุก repo ควรมี go.mod — แม้จะเป็น package เล็ก ๆ ก็ตาม

2. Redistributable license

pkg.go.dev ตรวจสอบ license ของ package — และจะแสดงเฉพาะ license ที่ redistributable (MIT, BSD, Apache 2.0, etc.)

license ที่ restrictive เกินไป หรือไม่พบ license → pkg.go.dev อาจไม่แสดง documentation บางส่วน หรือขึ้นคำเตือน

สิ่งที่ควรทำ: ใส่ LICENSE file ใน repo — MIT หรือ BSD หรือ Apache 2.0

3. Tagged version

Go modules ใช้ Git tags เป็นเวอร์ชัน — v1.0.0, v1.2.3 — และ go get ให้ความสำคัญกับ tagged versions ก่อน commit hash

ไม่มี tag → go get ต้องใช้ pseudo-version (v0.0.0-20250101000000-abc123) — ซึ่งไม่ stable และ importers ไม่มั่นใจ

สิ่งที่ควรทำ: tag ทุก release ด้วย semver — git tag v1.0.0 && git push origin v1.0.0

4. Stable version

Projects ที่ v0.x.x ถูกมองว่า experimental — breaking changes เกิดได้ตลอดเวลา — ไม่มีสัญญาว่าจะ backward compatible

เมื่อถึง v1.0.0 — คือสัญญาว่า public API จะไม่เปลี่ยนแบบ breaking ภายใน major version เดียวกัน

pkg.go.dev แสดงสถานะนี้ให้ทุกคนเห็น — "stable" หรือ "experimental" — และมันมีผลต่อการตัดสินใจของคนที่จะ import package ของคุณ

สิ่งที่ควรทำ: เมื่อ API นิ่ง — release v1.0.0 — และถ้าต้อง breaking change — ขึ้น major version ใหม่ (v2.0.0)

มากกว่า 4 เครื่องหมาย — สิ่งที่ pkg.go.dev ทำเบื้องหลัง

Documentation จาก source โดยตรง

pkg.go.dev ดึง source code จาก Go Module Mirror (proxy.golang.org) — และ generate documentation จาก source โดยตรง — ไม่ต้องอัปโหลดอะไรเอง

แค่ push code + tag → documentation ปรากฏบน pkg.go.dev ภายในไม่กี่นาที

Build Context

package บางตัวทำงานต่างกันบน OS/architecture ต่างกัน — pkg.go.dev แสดง build context ให้เห็น — เช่น linux/amd64, js/wasm

และมี dropdown ให้สลับดู document สำหรับ build context อื่น

การเพิ่ม package ใหม่

ถ้า package ยังไม่ปรากฏบน pkg.go.dev — แค่เข้า URL นั้นตรง ๆ แล้วกด "Request":

https://pkg.go.dev/example.com/my/module

หรือ go get package นั้นผ่าน proxy:

GOPROXY=https://proxy.golang.org go get example.com/my/module@v1.0.0

Retract เวอร์ชันที่มีปัญหา

ถ้า release เวอร์ชันที่มีบั๊กร้ายแรง — แก้ด้วย retract directive ใน go.mod:

retract v1.2.3 // security vulnerability

go get และ pkg.go.dev จะไม่แนะนำเวอร์ชันนั้นอีก — แต่ยังดาวน์โหลดได้ (retract ≠ delete)

เขียน package comment ให้ดี — มันไปโผล่บน go.dev

ประโยคแรกของ package comment คือสิ่งที่ go.dev ใช้เป็น search result snippet

// Package httputil provides HTTP utility functions, complementing the
// more common ones in the net/http package.
package httputil

ประโยคนี้คือสิ่งที่จะปรากฏเวลามีคน search บน go.dev — และทุกคนที่เปิดหน้า pkg.go.dev ของคุณ — จะเห็นประโยคนี้เป็นอันดับแรก

สิ่งที่ควรทำ: ประโยคแรกของ package comment ควรเป็น summary ที่สมบูรณ์ — ไม่ใช่แค่ชื่อ package

สรุป

pkg.go.dev คือ public scoreboard ของทุก Go package — และ 4 เครื่องหมายที่มันเช็คคือสิ่งที่ทุก package ควรมี

✅ go.mod
✅ Redistributable license (MIT/BSD/Apache)
✅ Tagged version (semver)
✅ Stable version (v1.0.0+)

ไม่มีอะไรซับซ้อน — แต่เป็นสัญญาณว่า "package นี้พร้อมให้คนอื่นใช้"

📚 อ่านต่อ:

pkg.go.dev/about — official documentation

Go Modules Reference — versioning, retract, compatibility

Ken Thompson — คนที่เขียนระบบปฏิบัติการใน 3 สัปดาห์

Gophernment — Fri, 17 Jul 2026 15:19:01 +0000

Ken Thompson — คนที่เขียนระบบปฏิบัติการใน 3 สัปดาห์

ปี 1969 เคน ทอมป์สัน อายุ 26 เป็นวิศวกรที่ Bell Labs

เขากับทีมเพิ่งเสียโปรเจกต์ Multics ซึ่งเป็นระบบปฏิบัติการที่ซับซ้อนเกินไปจนถูกยกเลิก Bell Labs ถอนตัว ทีมแตก โปรเจกต์ตาย

เคนมีเวลาเหลือเฟือ และมี PDP-7 ซึ่งเป็นคอมพิวเตอร์เก่าที่แทบไม่มีใครใช้

ใน 3 สัปดาห์ เขาเขียน Unix kernel, shell, editor, และ assembler ขึ้นมาบน PDP-7 — ทั้งหมดเป็น assembly — ภาษา B ยังไม่เกิดตอนนั้น

B ถูกสร้างขึ้นหลังจากนั้น — เพื่อใช้เขียน utility ต่าง ๆ แทน assembly — และนี่คือจุดเริ่มต้นของสายภาษา B → C → Go

ภาษา B — เกิดหลัง Unix เวอร์ชันแรก

Unix เวอร์ชันแรกสุด — สิงหาคม 1969 — เป็น assembly ล้วน

หลังจากนั้นไม่นาน Ken ก็เริ่มสร้าง B — โดยตัดทอนมาจาก BCPL — เพื่อให้มีภาษาระดับสูงไว้เขียน tools โดยไม่ต้องใช้ assembly ทั้งหมด

B มาจาก BCPL (Basic Combined Programming Language) ซึ่งพัฒนาโดย Martin Richards ที่ Cambridge ในปี 1966 BCPL เป็นภาษาที่ไม่มี type — ทุกอย่างคือ word — และออกแบบมาให้ compiler พกพาง่าย

Ken เอา BCPL มาตัดทุกอย่างที่ไม่จำเป็นออก — จนเหลือภาษาเล็กมากที่ทำงานได้บน PDP-7 ซึ่งมี RAM แค่ 4K words

PDP-7 Assembly → Unix v1 (1969, 3 สัปดาห์)
                    ↓
BCPL (Richards, 1966)
    ↓ ตัด feature, ลดขนาด
B (Thompson, 1969-1970)
    ↓ ใช้ rewrite Unix utilities (ไม่ใช่ kernel)
    ↓
    ↓ เพิ่ม type system, struct, portability
C (Ritchie, 1972)
    ↓ Unix v4 rewrite ด้วย C (1973)

B ไม่มี type system ไม่มีโครงสร้างข้อมูล มีแค่ word — เหมือนกับว่าเป็น BCPL เวอร์ชัน minimal

B ถูกใช้เขียน shell, utilities, และ tools ต่าง ๆ ของ Unix — แต่ kernel ยังเป็น assembly อยู่ จนกระทั่ง Dennis Ritchie สร้าง C ขึ้นมาในปี 1972

ทำไมต้อง B

PDP-7 มี assembly แต่นั่นไม่ใช่เหตุผลที่ดีพอที่จะใช้มัน

Ken ไม่เชื่อในการเขียน OS ด้วย assembly ทั้งระบบ — assembly เร็วแต่เขียนช้า แก้ยาก พกพาไม่ได้

การใช้ภาษาระดับสูง (แม้จะสูงนิดเดียวแบบ B) ทำให้:

เขียน shell, utilities เร็วขึ้นมาก
แก้ไขง่าย — ไม่ต้องเขียนใหม่เวลาย้ายเครื่อง
ใช้คนน้อยลง — Unix version แรกเขียนโดย 2 คน

จาก B → C → Unix → ทุกอย่าง

เมื่อทีมได้ PDP-11 ซึ่งเป็นเครื่องที่ใหญ่กว่า — B เริ่มมีปัญหา PDP-11 มี byte-addressing แต่ B ออกแบบมาเพื่อ word-addressing — ทำให้ใช้ความสามารถของเครื่องใหม่ได้ไม่เต็มที่

Dennis Ritchie จึงเริ่มเพิ่ม type system ลงใน B — int, char, struct, pointer — และ C ก็เกิดในปี 1972

Unix ถูก rewrite ด้วย C — และกลายเป็นระบบปฏิบัติการที่พกพาได้ — ครั้งแรกที่ OS ถูกเขียนด้วยภาษาระดับสูงที่ไม่ใช่ assembly

จาก Unix → BSD → Linux → macOS → iOS → Android — ทุกสิ่งที่เราใช้อยู่ทุกวันนี้ เริ่มจาก Ken Thompson — คนที่เขียน OS ใน 3 สัปดาห์เพราะเขาเบื่อ

สิ่งที่ Ken ทำหลังจากนั้น

UTF-8 — Ken Thompson และ Rob Pike ร่างมันระหว่างกินข้าวเย็นที่นิวเจอร์ซีย์ บนกระดาษรองจาน

Go — Ken Thompson, Rob Pike, Robert Griesemer สร้างขึ้นในปี 2007 ภาษาของ cloud-native era

Turing Award 1983 — ร่วมกับ Dennis Ritchie สำหรับการสร้าง Unix และ National Medal of Technology 1998 จากประธานาธิบดี Clinton

นิสัยการทำงานของ Ken

Ken เป็นคนที่ไม่ชอบประชุม ไม่เขียนเอกสาร ไม่ทำแผน — เขาแค่เขียนโค้ด

เวลามีคนถามว่าทำไม Unix ถึงดี — เขาตอบว่า:

"I can't tell you why Unix is good without sounding like I'm bragging."

Rob Pike เคยเล่าว่า:

"Ken สามารถถือโค้ดของระบบปฏิบัติการทั้งระบบไว้ในหัวได้ — และรู้ว่าบรรทัดไหนทำอะไร — โดยไม่ต้องเปิดไฟล์"

ทำไมเรื่องนี้ถึงสำคัญ

ปี 1969 — มนุษย์ไปดวงจันทร์ครั้งแรก — ปีเดียวกับที่ Ken Thompson เขียน OS ใน 3 สัปดาห์

56 ปีผ่านไป — เรายังใช้สิ่งที่เขาสร้าง

Shell ที่คุณเปิด terminal อยู่ตอนนี้ — ใช้ cd, ls, grep — ทั้งหมดมาจาก Unix

ภาษา Go ที่เราเขียน — ออกแบบโดย Ken Thompson ในวัย 64

UTF-8 ที่เว็บทั้งโลกใช้ — ออกแบบโดย Ken Thompson และ Rob Pike บนกระดาษรองจาน

นี่คือ Ken Thompson — คนที่เบื่อ Multics — แล้วเขียน Unix ขึ้นมาแทน

📚 อ่านต่อ:

The Evolution of the Unix Time-sharing System — Dennis Ritchie, 1979

Ken Thompson — Turing Award Lecture — 1984

UTF-8 history — Rob Pike, 2003

WSO2 ประกาศเดินหน้า Go แทน Java — วาง roadmap 10-20 ปี

Gophernment — Fri, 17 Jul 2026 10:33:39 +0000

WSO2 ประกาศเดินหน้า Go แทน Java

WSO2 — บริษัท enterprise middleware อายุ 20 ปีจากศรีลังกา — ประกาศทิศทางใหม่

ผู้บริหาร Sameera Jayasoma (VP) และ Sanjiva Weerawarana (CEO) เขียนโพสต์ชื่อ "Goodbye Java, Hello Go!" เมื่อ 26 ม.ค. 2026

นี่ไม่ใช่ startup ที่เปลี่ยนภาษาเล่น ๆ WSO2 คือผู้ผลิต API Manager, Identity Server, Micro Integrator — โค้ดฝั่งเซิร์ฟเวอร์ส่วนใหญ่เป็น Java มาตลอด 20 ปี

แต่ตอนนี้พวกเขาบอกว่า — ถ้าจะมองไปอีก 10-20 ปีข้างหน้า — Java ไม่ใช่คำตอบเดียวอีกต่อไป

📅 อ่านเมื่อ: กรกฎาคม 2026 — WSO2 ยังอยู่ในช่วงเริ่มต้น migration — โค้ดส่วนใหญ่ยังเป็น Java — บทความนี้เป็นการรายงานทิศทางเชิงกลยุทธ์ ไม่ใช่ผลลัพธ์ที่เกิดแล้ว

ไม่ใช่แค่ลอง

WSO2 ไม่ได้เพิ่งเริ่มใช้ Go พวกเขาใช้ Go ใน production มาแล้วหลายระบบ:

โปรเจกต์	คืออะไร	ภาษา
OpenChoreo	Developer Platform — CNCF Sandbox project	Go
Thunder	Cloud-native Identity Platform ตัวใหม่	Go
Ballerina Compiler	Compiler ของภาษา Ballerina ที่ WSO2 สร้างเอง — rewrite จาก Java	Go (ใหม่)
Platformer	Cloud platform ที่ WSO2 เข้าซื้อ	Go + Node.js
WUM	WSO2 Update Manager (CLI)	Go

Jayasoma เรียก OpenChoreo ว่า "most ambitious project" ของ WSO2 — และมันเขียนด้วย Go ทั้งหมด

การที่ทีม rewrite Ballerina compiler — ภาษาที่ตัวเองสร้าง — จาก Java ไป Go — นี่คือสัญญาณที่ชัดที่สุด

3 เหตุผลเบื้องหลัง

1. Java เป็น default ของปี 2005

WSO2 ก่อตั้งปี 2005 — ตอนนั้นไม่มีคำถามเลยว่าจะใช้ภาษาอะไรเขียน server-side enterprise infrastructure — Java เท่านั้น

20 ปีผ่านไป โลกเปลี่ยน Container, microservice, cloud-native กลายเป็นมาตรฐาน และ Go ถูกออกแบบมาเพื่อโลกนี้ — ไม่ใช่ปี 2005 อีกต่อไป

2. Go ถูกสร้างมาเพื่อ infrastructure

สิ่งที่ WSO2 ทำ — API Gateway, Identity Server, Integrator — เป็น network services ทั้งหมด

Go มีสิ่งที่ Java framework พยายามสร้างแต่ Go มีตั้งแต่เกิด: fast startup, small footprint, simple concurrency, static binary — ไม่ใช่ afterthought

3. WSO2 ใช้ Go จริง

OpenChoreo และ Thunder คือโปรเจกต์ใหม่ทั้งหมดที่เลือก Go เป็นภาษาแรก — ไม่ใช่การ rewrite ของเก่า — และ Ballerina compiler rewrite จาก Java → Go คือการตัดสินใจที่ต้นทุนสูงที่สุดเท่าที่พวกเขาเคยทำ

เมื่อทีมที่สร้างภาษา Ballerina ตัดสินใจเขียน compiler ใหม่ด้วย Go — มันจบแล้วสำหรับข้อถกเถียง "Go ใช้กับ enterprise ได้ไหม"

นี่ไม่ใช่ "Java จะตาย"

WSO2 ไม่ได้ประกาศว่า Java แย่ — 95% ของโค้ดยังเป็น Java — และการย้ายจะใช้เวลาเป็นทศวรรษ

สิ่งที่พวกเขาพูดคือ: "เมื่อมองไปข้างหน้า 10-20 ปี — Java ไม่ใช่ default อีกต่อไป — และ Go คือตัวเลือกที่เราวางไว้"

message ไม่ใช่ "ทิ้งทุกอย่างไปใช้ Go" — แต่คือ "เลือกเครื่องมือให้เหมาะกับงาน" — และสำหรับ server-side infrastructure ในยุค cloud-native — Go คือทางที่ WSO2 เลือก

สิ่งที่ Go มีที่ Java ไม่มี

	Java	Go
Deploy	JVM + dependencies	binary เดียว
Startup	ช้า (วินาทีถึงนาที)	เร็ว (มิลลิวินาที)
Memory footprint	สูง	ต่ำ
Concurrency	Threads (OS-managed)	Goroutines (lightweight, managed)
Build	Complex (Gradle/Maven)	`go build` — คำสั่งเดียว
Learning curve	สูง — ecosystem ใหญ่	ต่ำ — ภาษาเล็กโดยตั้งใจ

ตัวเลขเป็นทิศทางเชิงคุณภาพ — ไม่ใช่ benchmark แบบ controlled — ขึ้นอยู่กับ workload และ configuration

สรุป

WSO2 ประกาศทิศทางใหม่หลังจาก 20 ปีกับ Java — ไม่ใช่เพราะ Java ไม่ดี — แต่เพราะ Go ถูกออกแบบมาเพื่อโลกที่ WSO2 กำลังจะอยู่ไปอีก 10-20 ปี

และหลักฐานไม่ได้อยู่ที่ blog post — มันอยู่ที่ OpenChoreo (เขียน Go), Thunder (เขียน Go), Ballerina compiler (rewrite จาก Java → Go)

ถ้าบริษัท enterprise ระดับนี้วาง roadmap แบบนี้ — มันไม่ใช่ trend — มันคือ signal

📚 อ่านต่อ:

Goodbye Java, Hello Go! — WSO2 Blog (26 ม.ค. 2026) — Sameera Jayasoma & Sanjiva Weerawarana

ออกแบบ error ให้เป็น first-class citizen — ต่อจาก Double Report กับ Logging

Gophernment — Thu, 09 Jul 2026 15:37:30 +0000

ออกแบบ error ให้เป็น first-class citizen — ต่อจาก Double Report กับ Logging

สองบทความก่อนเราคุยกันเรื่อง:

Double Report — หลักการ "log หรือ return อย่างใดอย่างหนึ่ง"
Logging ใน microservice — วิธี log ให้ถูกที่ ถูกเวลา

บทความนี้คือภาค 3 — เมื่อ log ถูกที่แล้ว — แล้ว error ควรมีหน้าตายังไง

เพราะ error ไม่ใช่แค่ err.Error() — มันคือ API contract ระหว่าง layer — และการออกแบบ error ให้ดี จะทำให้ caller จัดการได้ถูกต้องโดยไม่ต้องอ่าน string message

1. Sentinel Errors — "error ที่รู้จักกันทั่ว"

Sentinel error คือ error ที่ประกาศเป็นตัวแปรระดับ package — ใช้ errors.Is เช็ค:

// repo/errors.go
var (
    ErrNotFound    = errors.New("not found")
    ErrConflict    = errors.New("resource already exists")
    ErrInvalidInput = errors.New("invalid input")
)

// service/user.go
func (s *Service) GetUser(ctx context.Context, id string) (*User, error) {
    user, err := s.repo.FindByID(ctx, id)
    if errors.Is(err, repo.ErrNotFound) {
        return nil, ErrNotFound  // map ไปเป็น error ของ service เอง
    }
    if err != nil {
        return nil, fmt.Errorf("GetUser: %w", err)
    }
    return user, nil
}

ข้อดี: caller ไม่ต้อง parse string — errors.Is(err, repo.ErrNotFound) — ชัดเจน

ข้อเสีย: sentinel error กลายเป็น public API ของ package — เปลี่ยนไม่ได้โดยไม่ break caller

Sentinel vs string matching

// ❌ แย่ — parse string
if strings.Contains(err.Error(), "not found") {
    // error message เปลี่ยน = โค้ดพัง
}

// ✅ ดี — sentinel
if errors.Is(err, repo.ErrNotFound) {
    // message เปลี่ยนยังไงก็ไม่พัง
}

2. Custom Error Types — "error ที่พกข้อมูล"

Sentinel บอกว่า "เกิดอะไร" — แต่บางครั้ง caller ต้องการข้อมูลเพิ่ม:

// service/errors.go
type ValidationError struct {
    Field   string
    Value   any
    Message string
    Err     error  // ← เก็บ sentinel error ไว้ข้างใน (ถ้ามี)
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation: %s=%v: %s", e.Field, e.Value, e.Message)
}

func (e *ValidationError) Unwrap() error {
    return e.Err  // ← ทำให้ errors.Is(e, ErrInvalidInput) ทำงานได้
}

// handler/user.go — ใช้ errors.As เพื่อดึงข้อมูล
var valErr *service.ValidationError
if errors.As(err, &valErr) {
    slog.InfoContext(ctx, "validation failed",
        slog.String("field", valErr.Field),
        slog.Any("value", valErr.Value),
    )
    http.Error(w, valErr.Message, http.StatusBadRequest)
    return
}

ความต่างจาก sentinel: errors.Is = "ใช่ error นี้ไหม?" — errors.As = "เป็น type นี้ไหม? + ดึงข้อมูล"

⚠️ Typed-nil interface trap: ถ้า function return (*ValidationError)(nil) (nil pointer) แล้ว assign เข้า error interface — err != nil จะเป็น true เพราะ interface เก็บ (type=*ValidationError, value=nil) — ไม่ใช่ (nil, nil) — classic Go footgun ที่ทั้ง junior และ senior เจอบ่อย — วิธีแก้: return nil แบบไม่มี type (return nil ไม่ใช่ return (*ValidationError)(nil)) — เพิ่มเติม: Go FAQ: nil error

3. Retryable Error — "error ที่บอกว่าให้ลองใหม่"

บาง error transient — ลองใหม่แล้วหาย (network timeout, connection reset, deadlock) — บาง error permanent — ลองกี่ครั้งก็ไม่หาย (not found, invalid input, permission denied)

// pkg/errors/retryable.go
type RetryableError struct {
    Err error
}

func (e *RetryableError) Error() string { return e.Err.Error() }
func (e *RetryableError) Unwrap() error { return e.Err }

func Retryable(err error) error {
    return &RetryableError{Err: err}
}

// service/order.go
func (s *Service) CreateOrder(ctx context.Context, req *CreateOrderReq) (*Order, error) {
    err := s.payment.Charge(ctx, req)
    if err != nil {
        if isNetworkTimeout(err) {
            return nil, Retryable(fmt.Errorf("Charge: %w", err))
        }
        return nil, fmt.Errorf("Charge: %w", err)
    }
    return &Order{ID: orderID}, nil
}

⚠️ ห้าม retry โดยไม่มี idempotency — โดยเฉพาะ payment: network timeout ไม่ได้แปลว่า payment gateway ไม่ได้รับ request — อาจ charge สำเร็จแล้วแต่ response ไม่กลับ — retry โดยไม่มี idempotency key = double charge — Stripe/Omise บังคับ Idempotency-Key header ทุก request — ห้าม retry การ charge โดยไม่มี key เด็ดขาด

// handler — retry แบบ loop + backoff + jitter + max attempts
// (ไม่ใช่ recursion — stack overflow ถ้า error เกิดซ้ำ)
func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
    const maxRetries = 3
    baseDelay := 100 * time.Millisecond

    for attempt := 0; attempt <= maxRetries; attempt++ {
        order, err := h.svc.CreateOrder(r.Context(), req)  // (*Order, error)
        if err == nil {
            json.NewEncoder(w).Encode(order)
            return
        }

        var retryable *RetryableError
        if !errors.As(err, &retryable) || attempt == maxRetries {
            slog.ErrorContext(r.Context(), "create order failed",
                slog.String("error", err.Error()),
                slog.Int("attempt", attempt),
            )
            writeError(w, err)  // ← ใช้ error code + status code
            return
        }

        // exponential backoff + jitter — ไม่ retry ทันที
        delay := baseDelay * (1 << attempt)  // 100ms, 200ms, 400ms
        jitter := time.Duration(rand.Int63n(int64(delay / 2)))
        slog.WarnContext(r.Context(), "retrying",
            slog.Int("attempt", attempt+1),
            slog.Int("max_retries", maxRetries),
            slog.Duration("delay", delay+jitter),
        )
        select {
        case <-time.After(delay + jitter):
        case <-r.Context().Done():
            return  // client disconnected — ไม่ต้อง retry
        }
    }
}

⚠️ Sync retry ใน handler = บล็อก goroutine: ที่ traffic สูง retry loop จะผูก HTTP handler thread ไว้เป็นวินาที — เสี่ยง connection exhaustion + client-side timeout — สำหรับ operation สำคัญที่ retry ยาว ควรพิจารณา async retry queue (เช่น NATS, Redis streams) แทนการ retry ใน handler โดยตรง — ตัวอย่างด้านบนเหมาะกับ retry สั้น (< 1 วิ) และ traffic ปานกลาง

💡 handler ต้อง integrate กับ idempotency store: retry loop อย่างเดียวไม่พอ — ต้อง wrap ด้วย idempotencyStore.Execute(...) เพื่อกัน double-submit จาก client:

// handler — retry loop + idempotency store ทำงานร่วมกัน
func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
    idempotencyKey := r.Header.Get("Idempotency-Key")
    if idempotencyKey == "" {
        writeError(w, &AppError{Code: ErrCodeInvalidInput, Message: "missing idempotency key"})
        return
    }

    order, err := h.idempotency.Execute(r.Context(), idempotencyKey, 5*time.Minute, func() (*Order, error) {
        // retry loop — ทำงานเฉพาะตอนได้ lock จาก idempotency store เท่านั้น
        var lastErr error
        for attempt := 0; attempt <= 3; attempt++ {
            order, err := h.svc.CreateOrder(r.Context(), req)
            if err == nil { return order, nil }
            lastErr = err  // ← จำ error ไว้ — loop จบแล้ว err ใน scope นี้หาย
            var retryable *RetryableError
            if !errors.As(err, &retryable) { return nil, err }
            // backoff + jitter...
        }
        return nil, fmt.Errorf("max retries exceeded: %w", lastErr)  // ← preserve retryable wrap
    })
    if err != nil {
        writeError(w, err)
        return
    }
    json.NewEncoder(w).Encode(order)
}

4. Error → HTTP Status Code — map แบบ declarative

Handler ไม่ควรมี switch-case ยาว ๆ — ใช้ helper:

// handler/errors.go
func httpStatus(err error) int {
    switch {
    case errors.Is(err, repo.ErrNotFound):
        return http.StatusNotFound
    case errors.Is(err, repo.ErrConflict):
        return http.StatusConflict
    case errors.Is(err, repo.ErrInvalidInput):
        return http.StatusBadRequest
    case errors.Is(err, ErrUnauthorized):
        return http.StatusUnauthorized
    default:
        return http.StatusInternalServerError
    }
}

// handler/user.go
func (h *Handler) GetUser(w http.ResponseWriter, r *http.Request) {
    user, err := h.svc.GetUser(r.Context(), id)
    if err != nil {
        slog.ErrorContext(r.Context(), "failed to get user",
            slog.String("error", err.Error()),   // ← log ใส่ internal details ได้
        )
        // ❌ อย่าส่ง err.Error() กลับไป client — leak internal details (SQL, stack, paths)
        status := httpStatus(err)
        http.Error(w, http.StatusText(status), status)  // ← "Not Found" ไม่ใช่ "FindByID: pq: relation..."
        return
    }
    json.NewEncoder(w).Encode(user)
}

ข้อดี: map error → status แบบรวมศูนย์ — เพิ่ม error type ใหม่แค่เพิ่ม case ใน httpStatus()

Advanced — error ที่บอก status code เอง

type HTTPError interface {
    error
    HTTPStatus() int
}

func (e *ValidationError) HTTPStatus() int { return http.StatusBadRequest }
func (e *AuthError) HTTPStatus() int       { return http.StatusUnauthorized }

func httpStatus(err error) int {
    var httpErr HTTPError
    if errors.As(err, &httpErr) {
        return httpErr.HTTPStatus()
    }
    return http.StatusInternalServerError
}

5. Error กับ Metric — วัดว่าระบบสุขภาพดีไหม

log อย่างเดียวไม่พอ — ต้องมี metric:

// middleware/metrics.go
func MetricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)

        duration := time.Since(start).Seconds()
        status := responseStatus(w)

        // ✅ normalize path — /users/123 → /users/{id} — กัน cardinality ระเบิด
        route := routePattern(r)  // เช่น chi.RouteContext(r.Context()).RoutePattern()

        requestDuration.Record(r.Context(), duration,
            attribute.String("method", r.Method),
            attribute.String("route", route),          // ← route template
            attribute.Int("status", status),
        )
        requestCounter.Add(r.Context(), 1,
            attribute.String("method", r.Method),
            attribute.String("route", route),
            attribute.Int("status", status),
        )
    })
}

⚠️ ห้ามใช้ r.URL.Path เป็น label — ถ้า path มี dynamic segment (/users/123, /orders/456) — แต่ละ ID คือ timeseries ใหม่ → cardinality ระเบิด Prometheus — ต้อง normalize เป็น route template (/users/{id}) — chi/gin/echo ทุกตัวมี RoutePattern() ให้

metric + trace + log — อย่าแยกกัน

// error log ต้องมี trace_id + span_id — ต่อกับ OTel ได้
span := trace.SpanFromContext(r.Context())
slog.ErrorContext(r.Context(), "create order failed",
    slog.String("trace_id", span.SpanContext().TraceID().String()),
    slog.String("span_id", span.SpanContext().SpanID().String()),
    slog.String("error", err.Error()),
)

circuit breaker — อย่า retry ใส่ downstream ที่กำลังป่วย

ถ้า payment gateway ล่ม — retry ทุกรอบมีแต่จะซ้ำเติม:

import "github.com/sony/gobreaker/v2"

var cb = gobreaker.NewCircuitBreaker[any](gobreaker.Settings{
    Name:    "payment-gateway",
    Timeout: 30 * time.Second,  // เปิด circuit นานสุด 30 วิ
})

func (s *Service) Charge(ctx context.Context, req *ChargeReq) error {
    _, err := cb.Execute(func() (any, error) {
        return nil, s.gateway.Charge(ctx, req)
    })
    if errors.Is(err, gobreaker.ErrOpenState) {
        return fmt.Errorf("Charge: circuit open — gateway is down")
    }
    return err
}

Error Budget / SLO — ทำไมต้องมี

SLO: 99.9% ของ requests ต้องสำเร็จภายใน 1 เดือน
Error Budget: 0.1% = ~43 นาที downtime/เดือน

ถ้า error rate สูงเกิน error budget → freeze feature, focus on stability

metric + alert:

// alert rule (Prometheus):
sum(rate(requests_total{status=~"5.."}[5m])) 
  / sum(rate(requests_total[5m])) > 0.001
→ pager ดัง → on-call ดู

6. ภาพรวม — error flow จาก repo ถึง user

user → handler → service → repo → database
                           ↑ error เกิดที่นี่

สิ่งที่ควรเกิดขึ้น:
1. repo:    return fmt.Errorf("FindByID: %w", err)     → wrap, ไม่ log
2. service: ตัดสินว่า error คืออะไร:
              errors.Is(err, sql.ErrNoRows) → return ErrNotFound
              errors.Is(err, timeout) → return Retryable(err)
3. handler: 
              errors.As(err, &valErr) → 400 Bad Request
              errors.As(err, &retryable) → retry
              errors.Is(err, ErrNotFound) → 404
              else → 500 + log + alert
4. metric:  requestCounter{status=500} → check SLO
5. alert:   error_rate > 0.1% → pager → on-call

Request ID — เชื่อม error กับ support ticket

user แจ้งปัญหา: "ผมกดสั่งซื้อแล้ว error" — ops จะ grep log ด้วยอะไร?

// middleware — generate request_id ให้ทุก request
func RequestIDMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        requestID := r.Header.Get("X-Request-ID")
        if requestID == "" {
            requestID = uuid.New().String()
        }
        w.Header().Set("X-Request-ID", requestID)
        ctx := context.WithValue(r.Context(), requestIDKey, requestID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

ทุก log ควรมี request_id:

slog.ErrorContext(ctx, "payment failed",
    slog.String("request_id", requestID),
    slog.String("trace_id", traceID),
    slog.String("error", err.Error()),
)

user ส่ง X-Request-ID: abc123 → ops grep abc123 → เจอทุก log, metric, trace ที่เกี่ยวข้อง

💡 request_id ≠ trace_id — request_id เกิดที่ edge (client/load balancer) — trace_id เกิดที่ tracing system — request_id ใช้ grep log แบบง่าย — trace_id ใช้ดู flow ข้าม service — ควรมีทั้งคู่

Error Codes — API contract ที่ machine อ่านได้

HTTP status อย่างเดียวไม่พอ — client (mobile app, partner API) ต้องรู้ว่า error อะไรแน่:

// pkg/errors/codes.go
type ErrorCode string

const (
    ErrCodeNotFound      ErrorCode = "ERR_USER_NOT_FOUND"
    ErrCodeDuplicate     ErrorCode = "ERR_DUPLICATE_EMAIL"
    ErrCodeInvalidInput  ErrorCode = "ERR_INVALID_INPUT"
    ErrCodeUnauthorized  ErrorCode = "ERR_UNAUTHORIZED"
    ErrCodeInternal      ErrorCode = "ERR_INTERNAL"
)

// เข้ากับ custom error type
type AppError struct {
    Code    ErrorCode `json:"code"`
    Message string    `json:"message"`
    Err     error     `json:"-"`  // ไม่ expose internal details
}

func (e *AppError) Error() string { return fmt.Sprintf("%s: %s", e.Code, e.Message) }
func (e *AppError) Unwrap() error { return e.Err }

// handler
func writeError(w http.ResponseWriter, err error) {
    var appErr *AppError
    if errors.As(err, &appErr) {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(httpStatus(err))
        json.NewEncoder(w).Encode(map[string]string{
            "code":    string(appErr.Code),
            "message": appErr.Message,
        })
        return
    }
    http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
}

client จะได้:

{"code": "ERR_USER_NOT_FOUND", "message": "user with id 42 not found"}

mobile app ใช้ code switch แสดงข้อความภาษาไทย — partner API ใช้ code automate retry logic — ไม่ต้อง parse string

⚠️ User enumeration attack (OWASP): ห้ามใช้ error code granular สำหรับ auth-sensitive endpoint — ถ้า login ใช้ ERR_USER_NOT_FOUND กับ ERR_INVALID_PASSWORD แยกกัน — attacker ยิง email ทีละตัว ดู response ก็รู้ว่า email ไหนมีในระบบ — สำหรับ login/password reset/register ต้อง return error code เดียวกัน (ERR_INVALID_LOGIN) ไม่ว่าจะ user not found หรือ wrong password — ส่วน resource endpoint ทั่วไป (get product, update profile) ใช้ granular code ได้ตามปกติ

idempotency — อย่าปล่อยให้ client double-submit

ส่ง Idempotency-Key ไปที่ payment gateway — แต่ถ้า client เอง retry เรียก CreateOrder ซ้ำ (double-click, network flake ฝั่ง frontend) — service ต้องป้องกันเอง:

// pkg/idempotency/store.go
type Store struct {
    redis *redis.Client
}

func (s *Store) Execute(ctx context.Context, key string, ttl time.Duration, fn func() (*Order, error)) (*Order, error) {
    // SETNX — atomic lock กัน race condition
    lockTTL := 1 * time.Minute  // lock สั้น แต่ต้องยาวกว่า timeout ของ downstream เสมอ
                                      // ถ้า s.payment.Charge timeout=15s → lock ควร ≥30s
    resultTTL := ttl            // result เก็บนานกว่า — 5-15 นาที

    locked, err := s.redis.SetNX(ctx, key, "processing", lockTTL).Result()
    if err != nil {
        return nil, fmt.Errorf("idempotency store unavailable: %w", err)
    }
    if !locked {
        // มีอีก request กำลังประมวลผล key นี้ — poll รอ result
        for i := 0; i < 10; i++ {
            select {
            case <-time.After(100 * time.Millisecond):
            case <-ctx.Done():
                return nil, ctx.Err()
            }
            cached, err := s.redis.Get(ctx, key).Result()
            if err == redis.Nil { continue }
            if err != nil { return nil, fmt.Errorf("idempotency: %w", err) }
            if cached == "processing" { continue }  // ยังไม่เสร็จ
            if cached == "failed-ambiguous" {
                return nil, fmt.Errorf("idempotency: previous attempt failed — check with gateway")
            }
            var order Order
            json.Unmarshal([]byte(cached), &order)
            return &order, nil
        }
        return nil, fmt.Errorf("idempotency: timeout waiting for concurrent request")
    }

    // ได้ lock — รัน fn จริง
    order, err := fn()
    if err != nil {
        var retryable *RetryableError
        if errors.As(err, &retryable) {  // reuse type เดียวกับ retry loop — ไม่สร้างเงื่อนไขคู่ขนาน
            s.redis.Set(ctx, key, "failed-ambiguous", resultTTL)
            return nil, fmt.Errorf("idempotency: ambiguous failure — check with gateway: %w", err)
        }
        s.redis.Del(ctx, key)  // non-retryable — safe, error เกิดก่อนถึง gateway
        return nil, err
    }

    data, _ := json.Marshal(order)
    s.redis.Set(ctx, key, data, resultTTL)
    return order, nil

💡 Reconciliation job: "failed-ambiguous" ไม่ใช่คำตอบสุดท้าย — ระบบ payment จริงต้องมี background job ที่ query transaction status จาก gateway (Stripe/Omise มี endpoint เช็ค charge status ด้วย idempotency key) แล้วอัปเดต state เป็น success/failed จริง — ไม่ใช่ปล่อยให้เห็น error ค้างจน TTL หมด

สรุป — เช็คลิสต์

✅ Sentinel errors สำหรับ "รู้จักกันทั่ว" (ErrNotFound, ErrConflict)
✅ Custom error types เมื่อต้องการพกข้อมูล — พร้อม Unwrap()
✅ ⚠️ typed-nil interface trap — return nil แบบไม่มี type
✅ Retryable error + idempotency key + loop/backoff/jitter + max attempts
✅ Circuit breaker — อย่า retry ใส่ downstream ที่กำลังป่วย
✅ httpStatus() — map error → status แบบรวมศูนย์
✅ ห้าม leak err.Error() กลับ client — ใช้ http.StatusText + error code
✅ Metric — cardinality-safe (route template, ไม่ใช้ raw path)
✅ Metric + trace + log ต้อง correlate กัน (trace_id + span_id)
✅ Request ID — grep ได้ตอน user แจ้งปัญหา
✅ Error Codes — machine-readable สำหรับ API contract
✅ Alert — error budget หมด → pager

📚 อ่านต่อ:

Double Report — เมื่อ Error ถูก Log ซ้ำซากใน Go

log ใน microservice — ควร log อะไร เมื่อไหร่

Google SRE Book: Error Budgets