DEV Community: Gophernment

tmux: เปลี่ยน terminal จอเดียวให้เป็นหลายจอ งานยาว ๆ ก็ไม่หายเมื่อ SSH หลุด

Gophernment — Fri, 04 Sep 2026 23:20:04 +0000

📅 เขียนเมื่อ: กันยายน 2026 | อ้างอิง tmux 3.7 (stable ตั้งแต่ มิ.ย. 2026)
⚠️ คำสั่งหลักไม่เปลี่ยนมานานหลายปี แต่เช็คเวอร์ชันตัวเองก่อนได้ด้วย tmux -V

เรื่องเริ่มจาก SSH หลุดกลางคัน

เคยไหม — นั่ง SSH เข้า server เพื่อรันงานที่กินเวลานาน เช่น build โปรเจกต์, เท database, รันเทสทั้งชุด, หรือ train โมเดล พอเรากด Enter แล้วงานมันวิ่ง... เราก็ทำอย่างอื่นต่อ เผลอตัวไป 10 นาที กลับมาดูอีกทีเจอข้อความประมาณนี้

Connection to server closed by remote host.

SSH หลุดตอนไหนไม่รู้ งานที่รันอยู่ตายไปกับมันด้วย เพราะต้องเริ่มใหม่ตั้งแต่ต้น นั่งเฝ้าจอไม่กล้าขยับก็ไม่ได้เรื่อง ไหนจะเวลาทำงานปกติที่ต้องเปิด terminal ทีละหลายจอ — จอหนึ่งไว้แก้โค้ด อีกจอไว้ดู log อีกจอไว้รัน test แล้วก็สลับไปมาไม่ทัน

สองปัญหานี้มีทางออกตัวเดียว: tmux

tmux คืออะไร กันแน่

tmux (อ่านว่า ti-mux) ย่อมาจาก terminal multiplexer — โปรแกรมที่ทำให้ terminal จอเดียวของคุณกลายเป็น "หลาย terminal" ได้ในตัวเดียว เป็นโปรเจกต์ open source ที่ Nicholas Marriott สร้างและปล่อยครั้งแรกเมื่อปี 2007 แล้วดูแลกันมาเรื่อย ๆ ถึงทุกวันนี้ที่ github.com/tmux/tmux

หลักการทำงานมันประมาณนี้: พอคุณสั่ง tmux ครั้งแรก มันจะรัน server ตัวหนึ่งขึ้นมาคอยดูแล "หน้าจอ" ทั้งหมดของคุณ โดย server ตัวนี้ ไม่ได้ผูกติดกับ terminal ที่คุณเปิดอยู่ — มันรันอยู่เบื้องหลังของเครื่องนั้น ๆ

นี่คือกุญแจสำคัญของเรื่องทั้งหมด: ใน terminal ปกติ พอ SSH หลุด หรือเราปิดหน้าต่าง terminal กระบวนการที่รันอยู่ในนั้นก็โดนฆ่าตามไปด้วย เพราะมันเป็นลูกของ terminal นั้น แต่กับ tmux พอ SSH หลุด แค่ "จอที่เราใช้ดู" หลุดไป — server กับงานในนั้นยังรันต่อเงียบ ๆ พอ SSH กลับมาใหม่ เราก็แค่ "ต่อจอ" เข้าไปดูงานเดิมที่ยังวิ่งอยู่

ฟังดูดีใช่ไหม ต่อไปมาดูของใน tmux กันว่ามันแบ่งหน้าจอยังไง

session, window, pane — สามชั้นที่ซ้อนกัน

tmux มีโครงสร้าง 3 เลเยอร์ซ้อนกัน:

session — กลุ่มงานหนึ่ง ๆ เช่น session ชื่อ dev-project-a กับอีก session ชื่อ ops-server คุณมีกี่ session ก็ได้ แต่ละ session แยกกันเป็นอิสระ
window — หน้าจอภายใน session เปรียบเหมือนแท็บใน browser: session หนึ่งมีได้หลาย window แล้วสลับไปมา
pane — การแบ่ง window ออกเป็นช่อง ๆ ให้เห็นพร้อมกันหลายจอ

┌─ tmux ────────────────────────────────────────────────┐
│  Session: "dev"  (กลุ่มงานทั้งหมด)                     │
│  ┌─ Window 0: code ─────────┐ ┌─ Window 1: server ──┐ │
│  │  pane 0: vim main.go     │ │  pane 0: ssh prod   │ │
│  │  ─────────────────────── │ └─────────────────────┘ │
│  │  pane 1: go run .        │                          │
│  └──────────────────────────┘                          │
│  [dev] 0:code*  1:server                   14:32       │
└────────────────────────────────────────────────────────┘

แถบล่างสุดคือ status bar — บอกว่าอยู่ session ไหน (dev), มี window อะไรบ้าง (ตัวเลข 0:code* ที่มีดอกจันคือ window ที่กำลังดูอยู่), และเวลาปัจจุบัน

จำง่าย ๆ ว่า session ใหญ่สุด ครอบ window ครอบ pane — session คือ "ห้องทำงาน", window คือ "โต๊ะทำงาน" ที่สลับกันได้, pane คือ "เอกสารที่วางบนโต๊ะเดียวกัน" ให้เห็นพร้อมกัน

คำสั่งพื้นฐานที่ใช้จริงทุกวัน

สามคำที่เพิ่งพูดถึง (session, window, pane) จะโผล่ในทุกคำสั่งด้านล่าง และก่อนอื่นต้องติดตั้งให้ได้ก่อน — macOS ใช้ Homebrew ส่วน Ubuntu/Debian (รวม Raspberry Pi OS) ใช้ apt:

# macOS
brew install tmux

# Ubuntu / Debian / Raspberry Pi OS
sudo apt install tmux

# เช็คว่าได้เวอร์ชันอะไร
tmux -V

เริ่ม session แรก

tmux new -s dev          # สร้าง session ใหม่ชื่อ dev แล้วเข้าไปเลย
tmux ls                  # (รันนอก session) ดูว่ามี session ไหนรันอยู่บ้าง
tmux attach -t dev       # กลับเข้า session ที่ชื่อ dev
tmux kill-session -t dev # ปิด session dev ให้สิ้นซาก

ถ้ารันแค่ tmux เฉย ๆ ก็ได้ — มันจะตั้งชื่อ session ให้เองแบบสุ่ม แต่การตั้งชื่อเอง (-s dev) จะทำให้จำง่ายเวลาเจอหลาย session พร้อมกัน

ปุ่ม "เรียก" ที่ชื่อ prefix

นี่คือหัวใจของ tmux ที่มือใหม่งงที่สุด: การจะสั่งอะไรใน tmux คุณต้องกด prefix ก่อนทุกครั้ง — ค่า default คือ Ctrl-b แปลว่ากด Ctrl ค้างไว้แล้วกด b พร้อมกัน แล้วปล่อย ตามด้วยปุ่มคำสั่ง เช่น

กด Ctrl-b แล้วกด d → คำสั่ง detach — หลุดออกจาก session แต่ session ยังรันต่อ

ลองคิดว่า Ctrl-b คือ "นี่ฉันจะสั่ง tmux นะ" แล้วปุ่มถัดไปคือ "สั่งอะไร" — เหมือนกด ⌘ หรือ Ctrl แล้วตามด้วยคีย์ลัดนั่นแหละ

ชุดคำสั่งที่ใช้บ่อยจริง ๆ เก็บไว้แค่นี้:

Ctrl-b d    detach: หลุดออกจาก session แต่ session ยังรันต่อ
Ctrl-b c    สร้าง window ใหม่ (เหมือนเปิดแท็บใหม่)
Ctrl-b 0-9  สลับไป window ที่ 0-9
Ctrl-b ,    ตั้งชื่อ window ปัจจุบัน (เช่น "code", "log")
Ctrl-b %    แบ่ง pane ซ้าย-ขวา
Ctrl-b "    แบ่ง pane บน-ล่าง
Ctrl-b o    กระโดดไป pane ถัดไป
Ctrl-b [    เลื่อนดู history ที่เลื่อนผ่านไปแล้ว (กด q เพื่อออก)
Ctrl-b x    ฆ่า pane ปัจจุบัน
Ctrl-b &    ฆ่า window ปัจจุบัน

เทคนิคจำ % กับ " ให้ได้: เครื่องหมาย % มีวงกลมสองวงอยู่ซ้าย-ขวา → ได้ pane ซ้าย-ขวา ส่วน " เป็นขีดตรงสองขีดเรียงคู่กัน → ได้ pane บน-ล่าง (สังเกตว่าผมเขียนเป็น "ซ้าย-ขวา/บน-ล่าง" ตามผลที่ได้ ไม่ใช่ศัพท์ vertical/horizontal ในเอกสาร — เพราะคนส่วนใหญ่รวมถึงผมตอนแรก งงกับคำนี้ประจำ)

และปุ่มที่ควรกดเป็นอย่างแรก ๆ คือ Ctrl-b ? — มันจะโชว์ key binding ทั้งหมดให้ดู ใครลืมอะไรให้กดอันนี้ก่อน

สถานการณ์จริง: งานยาว + จอแบ่งครึ่ง

1. SSH รันงานยาว แล้วเดินออกจากจอได้สบาย ๆ

ตัวอย่างจริงที่เจอทุกอาทิตย์ — เข้า server เพื่อรัน migration หรือ train โมเดลที่กินเวลาหลายชั่วโมง:

ssh user@server
tmux new -s train        # เปิด session ชื่อ train
python train.py          # รันงานยาว ๆ
Ctrl-b d                 # detach กลับมาที่ shell ปกติ
logout                   # ปิด SSH ได้เลย ไม่ต้องเฝ้า

ทีนี้ปิด notebook ไปนอนได้เลย พอตื่นมา:

ssh user@server
tmux attach -t train     # เห็น output ต่อจากบรรทัดเดิม งานยังวิ่งอยู่!

ความต่างจากเมื่อก่อนคือชัดเจน: ไม่ต้องนั่งเฝ้าจอ ไม่ต้องกลัว wifi หลุด — งานมันอยู่ใต้การดูแลของ tmux server ไม่ใช่ใต้ SSH connection ที่เปราะบางของคุณ

2. จอเดียว เห็นทั้งโค้ด ทั้ง log

อีกสถานการณ์ที่ใช้ทุกวัน — แก้บั๊กที่ต้องดู log ประกอบ:

tmux new -s fixbug       # เปิด session
vim main.go              # แก้โค้ด
Ctrl-b %                 # แบ่งจอซ้าย-ขวา
# พอ cursor ไปอยู่ฝั่งขวา:
tail -f /var/log/app.log # ดู log ไหลสด ๆ
Ctrl-b o                 # กระโดดกลับไป pane ซ้าย แก้โค้ดต่อ

ได้ผลลัพธ์แบบนี้ — ฝั่งซ้าย vim, ฝั่งขวา log ไหลสด แก้โค้ดปุ๊บเห็นผลปั๊บ ไม่ต้องสลับหน้าต่างไปมา:

┌─ pane 0: vim main.go ─────┬─ pane 1: tail -f log ────┐
│ func main() {             │ 14:31:02 request /login  │
│   server.Run()            │ 14:31:02 200 OK (42ms)   │
│ }                         │ 14:31:03 request /pay    │
│                           │ 14:31:03 500 ERROR!      │
└───────────────────────────┴──────────────────────────┘

ถ้าอยากให้ pane ไหนเต็มจอชั่วคราว (เช่นอยากจดจ่อกับ vim) กด Ctrl-b z เพื่อ zoom อีกทีก็กลับมาเป็นจอแบ่งเหมือนเดิม

ปรับ .tmux.conf ให้เข้ากับมือ

ทุกครั้งที่เปิด tmux มันจะอ่าน config จากไฟล์ ~/.tmux.conf ที่บ้านคุณ — ไฟล์นี้จะยังไม่มีในเครื่องใหม่ สร้างเองได้เลย นี่คือชุดเริ่มต้นที่เพื่อน ๆ หลายคนใช้กัน (รวมถึงผม) พร้อมคำอธิบายทีละบรรทัด:

# เปลี่ยนปุ่ม "เรียก" จาก Ctrl-b เป็น Ctrl-a
# (Ctrl-a อยู่แถว home row กดถนัดกว่า — แต่ถ้าไม่ชินก็ข้าม 3 บรรทัดนี้ไปได้)
unbind C-b
set -g prefix C-a
bind C-a send-prefix     # กด Ctrl-a สองที = ส่ง Ctrl-a จริง ๆ ให้โปรแกรมข้างใน

# เปิดโหมดเมาส์: คลิกเลือก pane, ลากขอบแบ่งขนาด, เลื่อนดู history เก่า
set -g mouse on

# ให้ window และ pane เริ่มนับที่ 1 (เริ่มที่ 0 แล้วงงทุกที)
set -g base-index 1
setw -g pane-base-index 1

# เพิ่ม buffer ให้เลื่อนดู history ได้ 5,000 บรรทัด (default 2,000)
set -g history-limit 5000

# reload config โดยไม่ต้องออกจาก tmux: กด prefix แล้ว r
bind r source-file ~/.tmux.conf

ถ้าแก้ config ตอนที่ยังไม่ได้ bind r (รอบแรก) ก็ reload มือได้: ใน tmux กด Ctrl-b ตามด้วย : พิมพ์ source-file ~/.tmux.conf แล้ว Enter — หรือง่ายสุดคือออกแล้วเข้า tmux ใหม่ เพราะมันอ่าน config อัตโนมัติทุกครั้งที่เริ่ม

ข้อควรจำ: ถ้าคุณเปลี่ยน prefix เป็น Ctrl-a ตาม config ด้านบน คำสั่งทุกอันที่ผมยกตัวอย่างด้วย Ctrl-b ข้างต้นก็ให้เปลี่ยนเป็น Ctrl-a ตามไปด้วยทั้งหมด

สรุป: เริ่มจาก session เดียวก่อน

tmux อาจดูน่ากลัวตอนแรกเพราะมีปุ่มลัดเยอะ แต่ความจริงคุณไม่ต้องจำทั้งหมด — จุดเริ่มต้นง่าย ๆ แค่เริ่ม session ด้วย tmux new -s <ชื่อ> จำ Ctrl-b d ไว้ตอนอยาก detach (งานไม่ตายแน่นอน) กลับมาทีหลังก็ tmux attach -t <ชื่อ> และที่เหลือถ้าลืมเมื่อไหร่ มี Ctrl-b ? ไว้เปิดดูคำสั่งทั้งหมดเสมอ

พอคล่องแล้วค่อยเพิ่ม window, pane, แล้วค่อยปรับ .tmux.conf — ส่วนผมตอนนี้ เปิด terminal ทีละสิบจอเป็นเรื่องของอดีตไปแล้ว และที่สำคัญกว่านั้น คืนไหนที่ต้องรันงานยาว SSH หลุดตอนไหนก็หลับได้สบาย

แหล่งอ้างอิง

tmux GitHub repository — release 3.7 (มิ.ย. 2026) และ CHANGES
tmux manual page — รายละเอียดคำสั่งและ key binding ตามค่า default
What's New in tmux — สรุป feature ใหม่ตั้งแต่ 3.4 เป็นต้นมา

Generic methods ใน Go 1.27: ฟีเจอร์ที่เคยถูกบอกว่า "ไม่มีทาง" แต่ community ผลักดันจนสำเร็จ

Gophernment — Tue, 01 Sep 2026 23:14:27 +0000

📅 เขียนเมื่อ: กันยายน 2026 | Go 1.27
⚠️ API/เวอร์ชันอาจเปลี่ยนแปลง — ตรวจสอบเอกสารล่าสุดก่อนใช้งาน

ปลายเดือนสิงหาคมที่ผ่านมา บัญชีทางการของ GoLand โพสต์คลิปวิดีโอสั้น ๆ ความยาว 36 วินาที ของ Robert Griesemer (หนึ่งในผู้ร่วมสร้างภาษา Go) เล่าเบื้องหลังของฟีเจอร์หนึ่ง พร้อมคำถามชวนคิดว่า:

"ทำไมทีม Go ถึงข้าม generic methods ตอน 1.18 แล้วกลับมาใส่ใน 1.27?"

คำตอบสั้น ๆ คือมันเป็นเรื่องราวยาว 5 ปี ที่เริ่มจากทีมออกแบบบอกว่า "ทำไม่ได้/ไม่น่าจะทำ" ไปจนถึงวันที่ community ผลักดันจนฟีเจอร์นี้กลายเป็นจริง — บทความนี้จะเล่าเรื่องนั้นให้ฟัง พร้อมอธิบายว่า generic methods คืออะไร และทำไมมันถึงสำคัญ

เกริ่น: Go 1.18 เปิดตัว generics แต่ทิ้งช่องว่างไว้

ย้อนไป กุมภาพันธ์ 2022 — Go 1.18 เปิดตัว generics (type parameters) ซึ่งถือเป็นการเปลี่ยนแปลงภาษา Go ครั้งใหญ่ที่สุดครั้งหนึ่ง หลังรอคอยกันมานานหลายปี

แต่ในดีไซน์นั้นมีข้อจำกัดหนึ่งที่หลายคนสังเกตเห็นทันที: method ประกาศ type parameters ของตัวเองไม่ได้

แปลง่าย ๆ ว่า generics ตอน 1.18 ใช้ได้กับ

ฟังก์ชันระดับ package: func Max[T cmp.Ordered](a, b T) T
และ type: type List[T any] struct { ... }

แต่ใช้กับ method ไม่ได้ — method ที่ผูกกับ receiver จะรับ type parameters เพิ่มเองไม่ได้ ต้องใช้ type parameters ของ type ต้นทางเท่านั้น

Generic methods คืออะไร

ขอทำให้เห็นภาพด้วยตัวอย่างคลาสสิก — สมมติมี List[T] แล้วอยากได้ method .Map ที่แปลง element จาก type T เป็น type U

ก่อน Go 1.27 เราทำแบบนี้ได้อย่างเดียว (เป็นฟังก์ชันระดับ package):

func Map[T, U any](l *List[T], f func(T) U) *List[U] {
    result := &List[U]{}
    for _, item := range l.items {
        result.items = append(result.items, f(item))
    }
    return result
}

// ใช้แบบนี้ — อ่านแล้วต้องไล่จากขวาไปซ้าย
mapped := Map(list, func(n int) string { return strconv.Itoa(n) })

ส่วนแบบที่หลายคนอยากได้ — เรียกเป็น method ต่อท้ายแบบ chain อย่างนี้ — เขียนไม่ได้:

// ❌ ก่อน Go 1.27: method ประกาศ type parameter U เองไม่ได้
func (l *List[T]) Map[U any](f func(T) U) *List[U] { ... }

Go 1.27 ทำให้แบบหลังนี้เป็นจริงแล้ว — method ประกาศ type parameters ของตัวเองได้ ซึ่งทำให้เขียน DSL และ chain ของ method ได้สะอาดขึ้นมาก (ตัวอย่างจริงใน standard library คือ math/rand/v2 ที่เปลี่ยนจาก generic function N[Int intType](Int) Int มาเป็น generic method (*Rand).N[Int intType](Int) Int)

ทำไมตอน 1.18 ถึงข้ามไป

เหตุผลหลักคือความซับซ้อนในการ implement ไม่ใช่ "ไม่อยากทำ"

เรื่อง dictionary — Go implement generics ด้วยการส่ง "type dictionary" ตามไปกับค่า การให้ method มี type parameters เอง แปลว่า dictionary ต้องถูกส่งผ่าน method value และ interface ซึ่งซับซ้อนกว่าฟังก์ชันธรรมดามาก
คำถามเรื่อง interface — ข้อถกเถียงที่ค้างมานาน: ถ้า method มี type parameters แล้วมันจะ "implement interface" ได้ไหม? ถ้าได้ จะตรวจ type ยังไง? ถ้าไม่ได้ แล้วทำไมไม่ใช้ฟังก์ชันธรรมดาแทน?

ประเด็นนี้ชัดเจนจากคอมเมนต์ของ Ian Lance Taylor (ผู้ร่วมออกแบบ generics) ใน proposal วันที่ 21 ตุลาคม 2021:

"This proposal is a non-starter unless someone can explain how to implement it."

และที่น่าจำคือตอนนั้น Go FAQ ถึงกับเขียนไว้ว่า:

"We do not anticipate that Go will ever add generic methods."

แล้ว community เปลี่ยนเกมยังไง

แต่สิ่งที่ทีมออกแบบประเมินไว้ต่ำไป คือแรงกดดันจากคนใช้งาน

proposal ตัวนี้ (golang/go #49085) ถูกเปิดไว้ตั้งแต่วันที่ 20 ตุลาคม 2021 — สองสามเดือนก่อน Go 1.18 จะออกด้วยซ้ำ — และสะสมความเห็นจากชุมชนไปเรื่อย ๆ จนมี 👍 กว่า 906 ครั้ง (ตัวเลขที่สูงมากสำหรับ proposal ภาษา Go)

use case ที่คนเอามาโชว์กันส่วนใหญ่เป็นเรื่องจริงจัง ไม่ใช่แค่ "อยากได้":

DSL สำหรับ stream processing — .Map(...).Filter(...) ต่อเป็น chain แบบที่ไลบรารีด้าน data pipeline ใช้กัน
DSL สำหรับ testing — Assert(actual).ToBe(expected) อ่านเป็นประโยคได้
DSL สำหรับ mocking — On(obj.Sum).WithArgs(7, 8).ThenReturn(15)

ทั้งหมดนี้เขียนด้วย method chaining ได้สวย แต่ถ้าไม่มี generic methods จะต้องถอยกลับไปเขียนเป็นฟังก์ชันระดับ package ซึ่งอ่านย้อนหลังและอุ้ยอ้ายกว่า

เมื่อเวลาผ่านไป 5 ปี คำตอบของคำถามเชิงเทคนิคก็ค่อย ๆ ชัดขึ้น จนในที่สุด Go 1.27 (สิงหาคม 2026) ก็ประกาศรองรับ generic methods อย่างเป็นทางการ — โดยปิด proposal #49085 เดิมเป็น "duplicate" ของ issue #77273 ที่ implement จริง

นี่คือจังหวะที่ Robert Griesemer เล่าในวิดีโอ — ว่าจุดเปลี่ยนจริง ๆ คือเสียงตอบรับจาก community ที่ยืนกรานว่า use case พวกนี้ "จำเป็น" ไม่ใช่ "ของเล่น"

ข้อจำกัดที่ยังเหลือ (สำคัญ)

อย่าเพิ่งดีใจจนลืมอ่าน footnote ใน release notes — Go 1.27 ระบุชัดว่า:

method ของ interface ยังประกาศ type parameters ไม่ได้
และ generic method ไม่สามารถ ไป implement interface method ได้

แปลว่า generic methods ใช้ได้กับ concrete type (struct ฯลฯ) แต่ยังแตะเรื่อง "generic interface method" ไม่ได้ — นี่คือขอบเขตที่ทีม Go ตั้งใจจำกัดไว้ให้ออกแบบต่อได้ในอนาคต

สรุป

เรื่องนี้เป็นกรณีศึกษาที่ดีมากของวิธีที่ Go (ในฐานะภาษา open source) รับมือกับฟีเจอร์ที่ขอเข้ามามาก:

ตอน 1.18 ทีมออกแบบตัด generic methods ออกอย่างจงใจ เพราะ implement ไม่ลงตัวและคำถามเรื่อง interface ยังค้าง
ชุมชนเปิด proposal (#49085) ยื่น use case จริง และกด 👍 กันเป็นพัน
ทีมตั้งท่าไว้ก่อน ("non-starter", FAQ บอก "ไม่มีทาง") แต่ก็ไม่ได้ปิดประตูถาวร
5 ปีต่อมา ปมเชิงเทคนิคถูกแก้ได้จริง → Go 1.27 ใส่ generic methods เข้ามา

ข้อคิดสำหรับคนเขียน Go: ฟีเจอร์ที่ทีมเคยบอกว่า "ไม่น่ามี" ก็มีวันเป็นจริงได้ ถ้า use case มัน "จริง" พอ — และตอนนี้ generic methods ก็พร้อมให้ใช้แล้วใน Go 1.27

แหล่งอ้างอิง

วิดีโอต้นเรื่อง (GoLand / Robert Griesemer) — https://x.com/GoLandIDE/status/2094810876565987652
Go 1.27 Release Notes (generic methods, issue #77273) — https://go.dev/doc/go1.27
Proposal #49085: allow type parameters in methods — https://github.com/golang/go/issues/49085
Type Parameters design doc (no parameterized methods) — https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

Aider: AI pair programming ใน terminal — เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

Gophernment — Sat, 29 Aug 2026 01:25:14 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | Aider 0.86.x, Claude Code 2.1.x, OpenAI Codex 0.150.x
⚠️ API/เวอร์ชันอาจเปลี่ยนแปลง — ตรวจสอบเอกสารล่าสุดก่อนใช้งาน

ถ้าคุณใช้ AI ช่วยเขียนโค้ดอยู่ตอนนี้ โฟลว์ของหลายคน (รวมถึงผมก่อนหน้านี้) คือเปิดเว็บแชตของ Claude หรือ GPT แล้วก็... ก๊อปโค้ดจาก editor แปะไป ถามว่า "ช่วยแก้บั๊กนี้หน่อย" รอคำตอบ แล้วก็ก๊อปโค้ดกลับมาแปะใน editor วนไปวนมา

โค้ดยาว ๆ แค่ไฟล์เดียว บางทีต้องก๊อปแปะเป็นสิบรอบ แถม AI ยังไม่เห็น context ของทั้งโปรเจกต์ มันเลยเดาเอาเองว่าไฟล์อื่น ๆ หน้าตาเป็นยังไง แล้วก็ให้โค้ดที่ไม่ตรงกับโค้ดจริงของเรามา

Aider เป็นหนึ่งในเครื่องมือที่แก้ปัญหานี้ — ให้ AI มา "จับคู่เขียนโค้ด" (pair programming) กับคุณใน terminal ตรง ๆ บทความนี้จะพาไปรู้จัก Aider แบบละเอียด แล้วปิดท้ายด้วยการเทียบหมัดต่อหมัดกับคู่แข่งสำคัญ 5 ตัว

Aider คืออะไร

Aider เป็นโปรแกรม command line ที่คุณเปิดในโฟลเดอร์โปรเจกต์ แล้วแชตกับ AI เพื่อสั่งให้มันแก้โค้ด ความต่างจากเว็บแชตคือ AI จะอ่านโค้ดจริงในเครื่องคุณ แก้ไฟล์จริง แล้วใช้ git commit การเปลี่ยนแปลงให้ด้วย message ที่สมเหตุสมผล

ตัวเลขที่ทางโปรเจกต์รายงานไว้: ดาวบน GitHub ราว 44,000 ดวง ติดตั้งไปแล้วกว่า 6.8 ล้านครั้ง ทำงานกับภาษาโปรแกรมได้มากกว่า 100 ภาษา (Python, JavaScript, Go, Rust, Ruby, PHP และอื่น ๆ)

เริ่มใช้งานง่าย ๆ

ติดตั้งแค่สองคำสั่ง ตัวแรกติดตั้ง installer แล้วตัวที่สองรันมันเพื่อ setup

python -m pip install aider-install
aider-install

ติดตั้งเสร็จ เข้าไปในโฟลเดอร์โปรเจกต์ แล้วเปิด Aider พร้อมระบุโมเดลกับคีย์ API

cd /to/your/project

# ใช้ DeepSeek
aider --model deepseek --api-key deepseek=<key>

# ใช้ Claude 3.7 Sonnet
aider --model sonnet --api-key anthropic=<key>

# ใช้ o3-mini
aider --model o3-mini --api-key openai=<key>

เปิดแล้วจะเข้าสู่หน้าจอแชตใน terminal พิมพ์สั่งงานภาษาไทยหรืออังกฤษก็ได้ เช่น "เพิ่มฟังก์ชัน validate email ในไฟล์นี้" แล้ว Aider จะแก้ไฟล์ให้ พร้อมโชว์ diff ของสิ่งที่เปลี่ยน

จุดเด่นของ Aider

หนึ่ง — เห็นทั้ง codebase Aider สร้าง "แผนที่" ของโปรเจกต์ทั้งก้อน ทำให้มันรู้ว่าไฟล์ไหนเรียกไฟล์ไหน จึงทำงานในโปรเจกต์ใหญ่ได้ดีกว่าการก๊อปโค้ดบางไฟล์ไปให้ AI เดา

สอง — git integration ทุกครั้งที่ Aider แก้โค้ด มันจะ commit ให้อัตโนมัติด้วย message ที่สมเหตุสมผล ใช้ git diff หรือ git log ตรวจย้อนได้เลย

สาม — เชื่อม LLM ได้เกือบทุกตัว จุดนี้คือสิ่งที่ทำให้ Aider ต่างจากคู่แข่งหลายตัว — มันไม่ผูกกับค่ายใดค่ายหนึ่ง ใช้ Claude, DeepSeek, OpenAI หรือแม้แต่ local model ผ่าน Ollama ก็ได้ เลือกเองตามงานและงบ

ข้อควรรู้ก่อนใช้จริง

ค่าใช้จ่าย — Aider เรียก LLM API โดยตรง ค่ายิง API ตกเป็นของคุณ (เลือกโมเดลให้เหมาะกับงาน)
ตรวจ diff ก่อนเสมอ — AI แก้โค้ดเก่งแต่ก็พลาดได้ ดู git diff ทุกครั้งก่อนปล่อยไป
เรื่อง privacy — ใช้โมเดล cloud โค้ดจะถูกส่งไปยังผู้ให้บริการนั้น ๆ ถ้ากังวลใช้ local model แทน

เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

ทีนี้มาดูภาพรวมตลาด — Aider อยู่ตรงไหนเมื่อเทียบกับตัวเด่น ๆ ทั้ง 5 ตัว

มิติ	Aider	Claude Code	OpenAI Codex	Cursor	GitHub Copilot	Cline
รูปแบบ	terminal CLI	terminal CLI	CLI + IDE + web	AI editor (VS Code fork)	IDE extension + CLI	SDK + extension + CLI
โอเพนซอร์ส	✅	❌	❌	❌	❌	✅
LLM	อิสระ (เกือบทุกตัว)	Claude เป็นหลัก	OpenAI เป็นหลัก	หลายค่าย	GPT + Claude	อิสระ (พกคีย์มาเอง)
Git commit	✅ อัตโนมัติ	✅	✅	✅ (ผ่าน editor)	✅	✅
ติดตั้ง	`pip install aider-install`	`npm i -g @anthropic-ai/claude-code`	`npm i -g @openai/codex`	โหลด app	ลง extension	marketplace / SDK
ราคา	ฟรี (จ่าย API เอง)	subscription / API	subscription / API	subscription	subscription	ฟรี (จ่าย API เอง)
เหมาะกับ	สาย terminal + อยากเลือก LLM เอง	สาย Claude ล้วน	สาย OpenAI ล้วน	อยากได้ editor ทั้งตัว	ใช้ editor เดิม เสริม AI	อยากปรับแต่งได้เต็มที่

อ่านตารางแล้วจะเห็นภาพชัด: จุดยืนของ Aider คือ "ตัวเดียวที่ทั้งโอเพนซอร์สและไม่ผูก LLM" ข้อดีคืออิสระและโปร่งใส ข้อเสียคือไม่มี editor UI สวย ๆ มาให้ (คุณต้องมี editor เอง) และต้อง setup คีย์ API เอง

เทียบแบบรวบรัด:

Claude Code — แรงและฉลาดมาก แต่ผูกกับ Claude และไม่โอเพนซอร์ส
OpenAI Codex — ระบบนิเวศ OpenAI แน่น แต่ก็ผูก OpenAI เช่นกัน
Cursor — ประสบการณ์ editor ดีที่สุด แต่เป็น closed source และเก็บค่าบริการรายเดือน
GitHub Copilot — ใช้กับ editor ที่มีอยู่แล้วสะดวก แต่จ่าย subscription และปรับแต่ง LLM ไม่ได้อิสระ
Cline — โอเพนซอร์สและยืดหยุ่นพอ ๆ กับ Aider แต่เป็น extension (ไม่ใช่ pure terminal) และพึ่งพา VS Code มากกว่า

เลือกยังไง

สาย terminal + อยากเลือก LLM เอง + ชอบโอเพนซอร์ส → Aider (หรือ Cline ถ้าอยากได้แบบมี UI ใน editor)
ใช้ Claude/OpenAI เจ้าเดียวอยู่แล้ว → Claude Code / Codex ตามค่ายที่ใช้
อยากได้ editor อัจฉริยะทั้งตัว → Cursor
ใช้ editor เดิม อยากเติม AI แบบไม่ต้องย้ายที่ → GitHub Copilot

ไม่มีตัวไหน "ดีที่สุด" แบบสัมบูรณ์ — มันขึ้นกับว่าโฟลว์ของคุณอยู่ที่ไหนอยู่แล้ว และยอมผูกกับค่ายไหนได้แค่ไหน

แหล่งอ้างอิง

Aider — https://aider.chat/
Aider Getting Started — https://aider.chat/#getting-started
Claude Code — https://www.anthropic.com/claude-code
OpenAI Codex — https://openai.com/codex
Cursor — https://cursor.com
GitHub Copilot — https://github.com/features/copilot
Cline — https://github.com/cline/cline

AI เขียน Go โบราณตลอด — JetBrains เลยทำ "กติกาการเขียน Go สมัยใหม่" ให้ agent แล้ว

Gophernment — Wed, 26 Aug 2026 05:52:28 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | ครอบคลุม Go 1.0–1.27
⚠️ ข้อมูลอัปเดต ณ วันที่เขียน — เวอร์ชัน/ฟีเจอร์อาจเปลี่ยนตามรอบ release ของ Go

ถ้าคุณเคยให้ AI coding agent เขียนโค้ด Go ให้ ลองสังเกตดูว่ามันเขียนออกมาเป็นยังไง ส่วนใหญ่แล้วมันจะเขียนแบบ "รุ่นพ่อ" ออกมา — ใช้ if a > b { return a } แทนที่จะใช้ max(a, b), เขียน loop หา element ทีละตัวแทน slices.Contains, หรือประกาศตัวแปรชั่วคราวเพื่อเอา pointer แทนที่จะใช้ new(...)

โค้ดแบบนี้รันได้นะ ไม่ผิดด้วย แต่มันไม่ใช่ Go แบบที่เราเขียนกันในปี 2026 แล้ว และนี่คือปัญหาที่ทีม JetBrains มองเห็น แล้วทำของชิ้นหนึ่งออกมาแก้ตรงจุด — ชื่อว่า go-modern-guidelines

ทำไม AI ถึงเขียน Go เก่า ทั้งที่ Go ออกฟีเจอร์ใหม่ตลอด

สาเหตุหลักมีสองอย่าง และมันซ้อนกันอยู่

อย่างแรก โมเดลภาษาเรียนรู้จากโค้ดบนโลก ซึ่งส่วนใหญ่เขียนขึ้นมาในช่วงหลายปีที่ผ่านมา โค้ด Go เก่า ๆ ที่วนอยู่ใน internet มหาศาลล้วนเป็นสไตล์ "ก่อนจะมีฟีเจอร์ใหม่" ทั้งนั้น โมเดลเลยจับ pattern แบบเก่ามาเป็น default

อย่างที่สอง Go ออกเวอร์ชันใหม่ทุก ๆ หกเดือน และแต่ละรอบก็มีของเล่นชิ้นเล็ก ๆ เข้ามาเรื่อย ๆ — min/max เข้ามาใน Go 1.21, for i := range n ใน Go 1.22, slices.Collect ใน 1.23, t.Context() ใน 1.24, errors.AsType ใน 1.26, และ encoding/json/v2 ใน 1.27 จังหวะมันไวกว่าที่โมเดลจะตามทัน

ผลลัพธ์คือ agent เขียนโค้ดที่ "ถูกแต่เชย" แล้วเราก็ต้องมาแก้ทีหลัง — ซึ่งก็คือสิ่งที่ Go team เองก็เห็นเหมือนกัน ถึงขั้นทำ analyzer ชื่อ modernize เอาไว้ auto-update โค้ดเก่าให้เป็น idiom ใหม่

แล้ว JetBrains แก้ยังไง

แทนที่จะรอให้โมเดลฉลาดขึ้นเอง ทีม JetBrains ทำสิ่งที่ตรงไปตรงมากว่ามาก คือเขียนกติกาให้ agent อ่านแล้วทำตาม

go-modern-guidelines เป็น repository ที่รวบรวม guideline 57 ข้อ ครอบคลุมตั้งแต่ Go 1.0 ยัน Go 1.27 แต่ละข้อประกอบด้วย "เขียนแบบนี้ ไม่ใช่แบบนี้" พร้อมโค้ดตัวอย่าง before/after ครบชุด แนวคิดง่าย ๆ คือให้ agent มี reference ที่ชัดเจนแทนที่จะเดาเอาเอง

ที่สำคัญคือมันไม่ใช่แค่เอกสารอ่านเล่น — ตัว guideline นี้ถูกแพ็กเป็น plugin/skill ให้ติดตั้งเข้าไปใน agent ได้ตรง ๆ รองรับทั้ง Junie, Claude Code, Codex, Cursor และ agent อื่น ๆ ผ่าน skills.sh พอติดตั้งแล้ว agent จะเรียกใช้ guideline นี้โดยอัตโนมัติตอนเจองานที่เกี่ยวกับ Go

ข้างในมีอะไรน่าสนใจบ้าง

ผมขอหยิบตัวอย่างที่เห็นแล้ว "นี่แหละ ที่ agent มักพลาด" มาให้ดูสักสองสามตัว

`min` / `max` แทนการเทียบเอง (Go 1.21)

// แบบเก่า
if a > b {
    return a
}
return b

// แบบใหม่
return max(a, b)

`slices.Contains` แทน loop หา (Go 1.21)

// แบบเก่า
found := false
for _, x := range items {
    if x == target {
        found = true
        break
    }
}

// แบบใหม่
found := slices.Contains(items, target)

`for i := range n` แทนการนับเอง (Go 1.22)

// แบบเก่า
for i := 0; i < n; i++ {
    doSomething(i)
}

// แบบใหม่
for i := range n {
    doSomething(i)
}

`errors.AsType` แทน `errors.As` แบบเก่า (Go 1.26)

// แบบเก่า
var e *MyError
if errors.As(err, &e) {
    handle(e)
}

// แบบใหม่ — ได้ตัวแปรตรง ๆ ไม่ต้องประกาศไว้ก่อน
if e, ok := errors.AsType[*MyError](err); ok {
    handle(e)
}

มีอีกเพียบ — clear(m) ล้าง map, maps.Clone/maps.Copy, slices.Sorted เรียงจาก iterator, sync.OnceValue สำหรับ memoize, context.AfterFunc สำหรับ cleanup ตอน cancel ไปจนถึงของใหม่สุดอย่าง generic methods และ encoding/json/v2 ที่เพิ่งเข้าใน Go 1.27

ลองใช้ดู

เริ่มใช้งานง่าย ๆ — ถ้าใช้ Claude Code ก็สั่งติดตั้ง marketplace แล้วให้มันโหลด skill นี้เข้าไปได้เลย (คำสั่งติดตั้งครบอยู่ใน README ของ repo) หรือถ้าใช้ agent ตัวอื่นที่รองรับ skills.sh ก็แค่รัน

npx skills add JetBrains/go-modern-guidelines

แค่นี้ agent ของคุณก็จะรู้จัก idiom ใหม่ ๆ ของ Go แทนที่จะยึดติดกับสไตล์เก่า ๆ ที่มันจำมาจากโค้ดบน internet

สรุป

ปัญหาที่ AI เขียน Go เชย ไม่ใช่เพราะโมเดลโง่ แต่เพราะข้อมูลเทรนเก่ากว่า release ล่าสุดของ Go ทางออกที่ JetBrains เสนอคือการยัด "ความรู้" เข้าไปใน context ของ agent ผ่าน guideline ที่ชัดเจน ซึ่งก็คือสิ่งที่ go-modern-guidelines ทำ — และมันไปทางเดียวกับ modernize analyzer ของ Go team เป๊ะ

สำหรับใครที่ปล่อยให้ AI เขียน Go บ่อย ๆ ผมว่านี่เป็น skill ที่คุ้มค่าติดไว้ ไม่ต่างจากใส่ style guide ให้ทีม dev เลย

แหล่งอ้างอิง

JetBrains/go-modern-guidelines — https://github.com/JetBrains/go-modern-guidelines
Go team — modernize analyzer (เครื่องมือ auto-update โค้ด Go เก่าให้เป็น idiom ใหม่)

จาก Vibe Coding สู่ Agentic Engineering — SDLC ใหม่ที่กำลังมาแทนที่

Gophernment — Sun, 16 Aug 2026 11:19:12 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | อ้างอิง: Whitepaper "The New SDLC With Vibe Coding" (พ.ค. 2026)
⚠️ ตัวเลขและเครื่องมือในบทความอาจเปลี่ยนตามเวลา

ลองนึกภาพตามนะครับ — เมื่อสิบปีก่อน ถ้าคุณจะเขียนฟีเจอร์ใหม่สักตัว คุณต้องนั่งไล่พิมพ์ syntax ให้ถูกต้องทีละบรรทัด ต้องรู้ว่าวงเล็บปิดตรงไหน semicolon อยู่ตรงไหน แล้วค่อยรันแล้วรอ error มาบอกว่าพิมพ์ผิดตรงไหนอีก

ตอนนี้ภาพนั้นกำลังหายไปเร็วมาก

มี whitepaper 51 หน้าเล่มหนึ่งชื่อ "The New SDLC With Vibe Coding" เขียนโดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis ตีพิมพ์บน Kaggle เมื่อเดือนพฤษภาคม 2026 มันพูดถึงเรื่องเดียวที่กำลังเขย่าวงการนักพัฒนา — การที่เราเปลี่ยนจาก "เขียนโค้ด" เป็น "เขียนเจตนา"

ตัวเลขที่เปิดมาทีแรกก็ทำเอาสะดุ้ง: ต้นปี 2026 มีนักพัฒนามืออาชีพ 85% ที่ใช้ AI coding agent เป็นประจำ ครึ่งหนึ่งใช้ทุกวัน และประมาณ 41% ของโค้ดใหม่ทั้งหมดถูก AI เขียนขึ้นมา

แล้วถ้าอยากเห็นภาพชัดที่สุดว่า "วงจรพัฒนาซอฟต์แวร์" (SDLC) เปลี่ยนไปยังไง ดูรูปนี้เลย — ฝั่งซ้ายคือวิธีที่เราทำงานกันมานับสิบปี ฝั่งขวาคือสิ่งที่กำลังมาแทนที่:

เห็นความต่างไหมครับ — ฝั่งซ้ายมนุษย์ต้องทำทุกขั้นตอนเรียงกันไปทีละเฟส แต่ฝั่งขวาเหลือแค่สองจุดที่มนุษย์ต้องอยู่จริง ๆ คือตอน "กำหนดเจตนา" กับตอน "ตรวจสอบคุณภาพ" ส่วนตรงกลางปล่อยให้ AI วน loop ไปเองจนกว่าจะผ่าน

แต่ก่อนจะไปต่อ ผมอยากให้เราเข้าใจคำหนึ่งให้ตรงกันก่อน เพราะมันเป็นหัวใจของเรื่องทั้งหมด

"vibe coding" คำนี้มาจากไหน

เดือนกุมภาพันธ์ 2025 Andrej Karpathy เขียนบรรยายวิธีเขียนโปรแกรมแบบใหม่ที่เขาเรียกว่า vibe coding — แนวคิดคือคุณ "ยอมแพ้ต่อ vibe เต็มตัว แล้วลืมไปเลยว่าโค้ดมีอยู่จริง" คุณแค่บอกสิ่งที่อยากได้เป็นภาษาธรรมดา รับผลลัพธ์จาก AI มาใช้ และถ้ามันพังก็ copy ข้อความ error กลับไปให้ AI แก้ให้

คำนี้ระเบิดขึ้นมาทันที เพราะมันไปแตะสิ่งที่คนทำกันอยู่เงียบ ๆ มานานแต่ไม่มีคำเรียก

แต่พอมันดัง คำก็เลยถูกใช้จนความหมายเลอะเทอะ — senior engineer ที่ใช้ AI ช่วย implement ฟีเจอร์ที่ spec ครบถ้วน ก็ถูกเรียก "vibe coding" เหมือนกับคนที่ prompt มั่ว ๆ แล้วยัดโค้ดขึ้น production ไปดื้อ ๆ

จนกระทั่งต้นปี 2026 Karpathy เองออกมายอมรับว่า framing เดิมมันแคบเกินไป และแนะนำคำใหม่คือ "agentic engineering" สำหรับปลายทางสายที่มีวินัยมากกว่า

เส้นแบ่งจริง ๆ ไม่ใช่ "ใช้ AI หรือไม่" แต่อยู่ที่ "ตรวจสอบแค่ไหน"

นี่คือประเด็นที่สำคัญที่สุดของ whitepaper — vibe coding กับ agentic engineering ไม่ใช่สองสิ่งที่แยกขาดจากกัน แต่อยู่บนเส้นเดียวกัน (spectrum) และสิ่งที่แยกสองปลายออกจากกันไม่ใช่เรื่องว่าใช้ AI หรือเปล่า แต่เป็นเรื่องว่าเราตรวจสอบผลลัพธ์จาก AI มากแค่ไหน

ลองไล่ดูทีละมิติ:

การระบุเจตนา — ฝั่ง vibe coding คือพิมพ์ prompt สบาย ๆ ไม่คิดเยอะ ฝั่ง agentic engineering คือมี spec, architecture doc และ memory file ครบถ้วน
การตรวจสอบ — ฝั่งหนึ่งคือ "เอ๊ะ มันดูใช้ได้มั้ง" อีกฝั่งคือมี test suite, CI/CD gate และ LM judge คอยตรวจ
การแก้ error — ฝั่งหนึ่ง copy error กลับไปให้ AI เฉย ๆ อีกฝั่งคือคนหาต้นตอให้เจอก่อน แล้วให้ AI implement ฟิกซ์

หัวใจจริง ๆ อยู่ที่กลไกตรวจสอบสองตัวที่ทำงานคู่กัน: tests ตรวจส่วนที่ "กำหนดได้" (ฟังก์ชันรับ input นี้ต้องคืน output นั้น) ส่วน evals ตรวจส่วนที่ "กำหนดไม่ได้" (agent เลือกเส้นทางถูกไหม ใช้ tool ถูกไหม ผลลัพธ์ถึงมาตรฐานไหม)

whitepaper พูดตรง ๆ ว่า ถ้าไม่มีทั้ง tests และ evals — ต่อให้ prompt เก่งแค่ไหน มันก็ยังเป็น vibe coding อยู่ดี

แล้วเราควรยืนตรงไหนของเส้นนี้? คำตอบคือขึ้นกับ "เดิมพัน" ของงาน — prototype ในวันหยุดก็ vibe coding ได้เต็มที่ แต่ API ที่คุมธุรกรรมการเงินต้อง agentic engineering เท่านั้น งานจริงส่วนใหญ่อยู่ตรงกลาง และทักษะที่แท้จริงคือรู้ว่าจะขีดเส้นตรงไหนของแต่ละงาน

ทักษะที่แท้จริงไม่ใช่ "prompt" แต่เป็น "context"

มี insight หนึ่งที่ whitepaper ย้ำหลายรอบ และผมว่ามันคือของขวัญที่ดีที่สุดในเล่ม: คุณภาพของโค้ดจาก AI ไม่ได้ขึ้นกับความฉลาดของ prompt แต่อยู่ที่คุณภาพของ context ที่เราป้อนให้มัน

นี่คือที่มาของคำว่า context engineering

ลองคิดแบบนี้ — ถ้าคุณจะให้สมาชิกใหม่มาช่วยเขียนโค้ดในโปรเจกต์ คุณจะไม่ยัดทุกอย่างให้เขารู้ในประโยคเดียว แต่คุณจะให้เขาอ่าน documentation ดู diagram รู้จัก convention ของทีม แล้วค่อยลงมือ

กับ AI ก็เหมือนกัน มันไม่ได้ต้องการ "คำสั่งที่แต่งมาฉลาด ๆ" แต่มันต้องการ context แบบเดียวกับที่มนุษย์เก่ง ๆ ต้องการถึงจะทำงานดีได้

context พวกนี้แบ่งเป็นสองชั้นที่สำคัญ:

Static context — โหลดตลอดเวลา เช่น AGENTS.md, CLAUDE.md, memory ของโปรเจกต์ มันแพง เพราะทุก token อยู่ในทุก interaction ไม่ว่าจำเป็นหรือไม่
Dynamic context — โหลดเฉพาะเมื่อต้องการ เช่น skill ที่ถูกเรียกเมื่อ task ตรง, เอกสารที่ดึงจาก RAG, ประวัติ session มันประหยัด เพราะจ่าย token เฉพาะตอนใช้

และกุญแจที่ทำให้จัดการสองชั้นนี้ได้คือ Agent Skills — แพ็กเกจความรู้ที่ agent โหลดเฉพาะเมื่องานเรียกใช้ แทนที่จะยัดทุกอย่างลง system prompt ตั้งแต่วินาทีแรก

ประโยคที่ผมชอบที่สุดในหัวข้อนี้คือ:

คำถามไม่ใช่ "จะหลอก AI ให้เขียนโค้ดดี ๆ ได้ยังไง" แต่อยู่ที่ "ถ้าจะมีสมาชิกใหม่มาช่วยงาน เขาต้องรู้อะไรบ้าง แล้วเราจะ encode ความรู้นั้นให้ AI ใช้ยังไง"

model ไม่ใช่ทุกอย่าง — แนวคิด Harness ที่คนส่วนใหญ่เข้าใจผิด

ตอนนี้ขอเปลี่ยนจังหวะหน่อย เพราะส่วนถัดไปคือจุดที่ผมเห็นคนเข้าใจผิดกันเยอะที่สุด

เวลาคนใช้ AI coding agent แล้วผลออกมาแย่ สัญชาตญาณแรกของเราคือโทษ model — "model นี้โง่" "รุ่นใหม่ยังไม่เก่ง" แต่ whitepaper บอกว่านั่นคือ intuition ที่ผิด และมันพาเราลงทุนผิดทาง

ความจริงคือ model เป็นแค่ "เครื่องยนต์" ตัวเดียวในโรงงาน — เครื่องยนต์อย่างเดียวผลิตรถออกมาไม่ได้ ต้องมีสายพาน เฟือง และเซนเซอร์ความปลอดภัยคอยประกอบ

สิ่งที่ห่อหุ้ม model อยู่รอบ ๆ — prompt, tools, sandbox, sub-agent, observability, guardrails — เรียกรวมว่า Harness

Agent = Model + Harness

หลักฐานที่ทำให้เรื่องนี้จับต้องได้จริง:

บน Terminal Bench 2.0 มีทีมหนึ่งดัน coding agent จากนอก Top 30 ขึ้นไป Top 5 ได้ โดยเปลี่ยนแค่ harness อย่างเดียว — ไม่เปลี่ยน model เลยแม้แต่ตัวเดียว
งานวิจัยของ LangChain ยกคะแนน agent บน benchmark เดียวกันขึ้น 13.7 คะแนน ด้วยการปรับแค่ system prompt, tools และ middleware รอบ model ที่ fixed ไว้

สรุปเป็นประโยคที่ควรแปะไว้หน้ามอนิเตอร์: เมื่อ agent ทำพลาด อย่าเพิ่งโทษ model — ความจริงส่วนใหญ่คือ configuration ที่พลาด ไม่ว่า tool จะหายไป กฎคลุมเครือ guardrail ไม่มี หรือ context เต็มไปด้วย noise

ปัญหา 80% — ทำไม AI ยังแทนเราไม่ได้ (และก็ไม่ควร)

แล้วทำไมเราถึงยังต้องการคนอยู่ตรงกลาง? whitepaper เรียกมันว่า "80% problem" — AI สร้างโค้ด 80% แรกของฟีเจอร์ได้เร็วมาก แต่ 20% ที่เหลือ ทั้ง edge case, error handling, จุด integration และ requirement ละเอียดอ่อน ต้องอาศัยความรู้เชิงลึกที่ model ยังไม่มี

และที่น่ากังวลกว่าคือ nature ของ error มันเปลี่ยนไปแล้ว — จาก "พิมพ์ syntax ผิด" กลายเป็น "เข้าใจ business logic ผิด", "ไม่ถามตอน requirement คลุมเครือ", "พลาด edge case" หรือ "ตัดสินใจ architecture ที่สร้างหนี้ระยะยาว" ซึ่งตรวจจับยากมากเพราะโค้ดมันดูถูก และอาจผ่าน test พื้นฐานด้วยซ้ำ

ตัวเลขที่หลายคนชอบอ้างว่า AI ทำให้เร็วขึ้น 25–39% ก็ต้องอ่านให้ละเอียด — งานวิจัยของ METR พบว่านักพัฒนาที่มีประสบการณ์ใช้ AI แล้วช้าลง 19% ในงานบางประเภท เพราะเวลาโดนกลืนไปกับการตรวจ แก้ และไล่บั๊กโค้ดที่ AI สร้าง

คนที่ใช้ AI ได้เก่งที่สุดจึงไม่ใช่คนที่รับทุกอย่างที่ AI ยื่นให้ แต่คือคนที่รู้ว่าเมื่อไหร่ควรให้ AI ทำ (งานที่ spec ชัด) และเมื่อไหร่ควรเก็บสมาธิของตัวเองไว้ (requirement คลุมเครือ, trade-off ทาง architecture, การ verify ความถูกต้อง)

เงินที่ซ่อนอยู่ใต้ vibe coding

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

vibe coding ดูถูกมากตอนเริ่ม — จ่าย subscription เดือนละไม่กี่ร้อย แล้ว prompt ไปเรื่อย ๆ แต่ whitepaper ชี้ให้เห็นว่ามันมี OpEx ที่แฝงตัวและทบต้นอยู่สามก้อน:

Token burn — ยัดไฟล์ก้อนใหญ่แบบไม่มีโครงสร้างเข้า context แล้วให้ AI แก้ผิดซ้ำไปมา วน prompt เผา token เปลือง ๆ
Maintenance tax — โค้ดที่เกิดจาก prompt มั่ว ๆ ไม่มีโครงสร้าง พอบั๊กโผล่ทีหลัง 6 เดือน คนต้องนั่ง reverse-engineer "โค้ดสปาเก็ตตี้" กันเป็นวัน ๆ
Security remediation — ไม่มี eval harness คุม = สร้างโค้ดเร็ว = สร้างช่องโหว่เร็ว และค่าแก้ช่องโหว่ใน production แพงกว่าตอน design เป็นทวีคูณ

ฝั่ง agentic engineering กลับกัน — จ่าย upfront กับการออกแบบ API schema, เขียน test suite, จัดโครงสร้าง context ให้ดีตั้งแต่แรก ซึ่งแพงกว่าในตอนเริ่ม แต่ marginal cost ต่อฟีเจอร์ถัด ๆ ไปลดฮวบ เพราะ AI ทำงานอยู่ใน "โรงงาน" ที่มีกฎคุม output เลยมีโครงสร้าง ผ่าน test และตรง standard

ส่วน context engineering เองก็กลายเป็นกลยุทธ์การเงินไปโดยปริยาย — LLM คิดเงินทุก token ที่เราส่งไป การยัด repo 100,000 token เข้าทุก prompt คือการเผาเงินแบบไม่จำเป็น และทางแก้คือ intelligent model routing: ใช้ model ใหญ่แพงกับงานที่ซับซ้อน แต่ route งานง่าย ๆ (generate test, code review, CI/CD) ไปให้ model เล็กที่ถูกกว่ามาก

แล้วควรเริ่มยังไง

whitepaper ปิดท้ายด้วย checklist ที่เอาไปใช้ได้จริง ผมสรุปเฉพาะตัวที่คิดว่าสำคัญสุดมาให้

ถ้าคุณเป็น developer เริ่มจากสามอย่างนี้พอ:

ตั้ง AGENTS.md ให้โปรเจกต์ — เริ่มจากสิบบรรทัด: stack, convention, กฎตายตัว, workflow แล้วค่อยเพิ่มกฎทุกครั้งที่ agent ทำสิ่งที่ไม่อยากให้ทำซ้ำ
เขียน tests + evals ก่อน generate โค้ด — มันคือ "สัญญา" กับ AI สื่อเจตนาได้แม่นกว่า prompt ไหน ๆ
review ทุกบรรทัดที่จะ ship — ระแวงโค้ดที่ "ฉลาดเกินไป" เช็ค import ว่าเป็นแพ็กเกจจริง ตรวจ error handling ให้ครบ

ถ้าคุณเป็น leader เรื่องสำคัญสุดคือการยกระดับมาตรฐานของทีม:

ทำให้ context engineering เป็น practice ระดับทีม — AGENTS.md, system prompt และ eval suite ต้องถูก review ใน PR, version กับโปรเจกต์ และมีคนรับผิดชอบชัดเจน
ตั้งมาตรฐานที่ "eval" ไม่ใช่ "demo" — demo ผ่านแค่แปลว่าทำสำเร็จครั้งเดียว แต่ eval ผ่านแปลว่าทำสำเร็จทุกครั้ง

ทิ้งท้าย

ถ้าจะย่อ 51 หน้าให้เหลือบรรทัดเดียว ผมขอสรุปแบบนี้:

เราไม่ได้เลิกเขียนโค้ด — เราแค่เปลี่ยนจาก "เขียน syntax" เป็น "เขียนเจตนา" แล้วปล่อยให้เครื่องจักรรับผิดชอบการ implement ส่วนมนุษย์เก็บงานที่เหลือไว้: การตัดสินใจ รสนิยม และการตรวจว่าของที่ออกมาดีจริง

และจุดแบ่งระหว่าง vibe coding ที่น่ากลัว กับ agentic engineering ที่เชื่อถือได้ ไม่ได้อยู่ที่ tool ที่เราเลือกใช้ แต่อยู่ที่ ว่าเราตั้ง harness รอบ ๆ AI ไว้แน่นแค่ไหน

📚 อ้างอิง: The New SDLC With Vibe Coding — Addy Osmani, Shubham Saboo, Sokratis Kartakis (Kaggle, พฤษภาคม 2026)
🔗 อ่านต้นฉบับ: https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

Goish: พอร์ตรันไทม์ของ Go ทั้งตัวลงใน no_std Rust

Gophernment — Sat, 15 Aug 2026 02:40:33 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | Goish (goish.cogentica.ai)
⚠️ โปรเจกต์เพิ่งเปิดตัว — รายละเอียด/เวอร์ชันอาจเปลี่ยนแปลง ตรวจสอบจาก GitHub ก่อนใช้งาน

ถ้าคุณเขียน Go มาสักพัก คุณน่าจะเคยอยากได้สองอย่างพร้อมกัน — concurrency model ของ Go (goroutine, channel, select) กับ ความปลอดภัยด้าน memory ของ Rust (ownership, ไม่มี GC) ปกติแล้วสองอย่างนี้อยู่คนละโลก: Go ให้ runtime มาให้แต่มี garbage collector, Rust ให้ ownership มาแต่ concurrency ต้องประกอบเองจาก async/futures

มีคนพยายามเชื่อมสองโลกนี้เข้าด้วยกันแล้ว — ชื่อโปรเจกต์ว่า Goish ผลงานของ Chanwit Kaewkasi (@chanwit) วิศวกรชาวไทยจากโคราช ภายใต้บริษัท Cogentica AI

Goish คืออะไร

นิยามสั้น ๆ ที่เจ้าตัวเขียนไว้ในหน้าแรก: "A Rust runtime for Go people" — รันไทม์ของ Go สำหรับคนที่เขียน Go

ถ้าขยายให้ละเอียด: Goish คือการพอร์ต standard library และ runtime ของ Go 1.25 ลงไปใน Rust แบบ no_std — ไม่พึ่ง glibc, ไม่พึ่ง std ของ Rust, ไม่พึ่ง Tokio, ไม่มี garbage collector มัน ship ทุกอย่างมาเองตั้งแต่ _start, page allocator, size-class heap, M:N scheduler, channel, select!, sync primitives, ไปจนถึง net/http และ crypto/tls

ผลลัพธ์คือ binary ไฟล์เดียวแบบ static เหมือน Go — ldd รันแล้วบอกว่า "not a dynamic executable"

แต่สิ่งที่ทำให้ Goish ต่างจากโปรเจกต์ "เขียน Go ให้เป็น Rust" ทั่วไป คือวิธีที่มันให้เครดิตกับต้นทาง — เรื่องนี้แหละคือหัวใจของที่มาที่ไป

ทำไมถึงคิดทำตัวนี้ (ที่มาที่ไป)

แรงจูงใจหลักไม่ใช่ "อยากให้ Rust เขียนง่ายเหมือน Go" ธรรมดา ๆ แต่เป็นเรื่องของ compliance และ provenance

ลองนึกภาพ: ทีมคุณเขียน Go อยู่ แล้วต้องย้ายไป Rust (ด้วยเหตุผลเรื่อง memory safety หรือนโยบายบริษัท) ระหว่างทางคุณต้อง "พอร์ต" โค้ด — เอาโค้ดจาก Go มาเขียนใหม่เป็น Rust แล้วคำถามสำคัญก็ผุดขึ้น:

AES-GCM ใน binary ตัวนี้ เป็น implementation ที่ Go review แล้ว หรือเป็นของที่เราเขียนประมาณเอา?

เครื่องมือ supply-chain ยุคปัจจุบันอย่าง SLSA provenance หรือ SBOM ตอบคำถามนี้ไม่ได้ — มันอธิบายแค่ว่า binary ถูก build มาจากไหน (builder ไหน, commit อะไร, digest อะไร) แต่อธิบายไม่ได้ว่าโค้ดข้างในถูก port มาอย่างซื่อสัตย์แค่ไหน SBOM จะบันทึกว่า "goish 0.1.0" แล้วจบ — มันแยกไม่ออกว่า crypto ในนั้นคือของจริงหรือของก๊อป

Goish แก้ด้วยการบันทึกที่มาเป็นฟังก์ชันต่อฟังก์ชัน:

// go: sdk 1.25.5 crypto/internal/fips140/aes/gcm/gcm.go:31-46 newGCM

บรรทัดนี้เขียนไว้เหนือ port แต่ละตัว — บอกว่าโค้ดตรงนี้ port มาจากไฟล์ไหน บรรทัดไหน ใน Go 1.25.5 และมี CI ที่เปิด Go tree ขึ้นมาเช็คทุก commit ว่าตำแหน่งที่อ้างยังถูกต้องอยู่

ทำไมเรื่องนี้ถึงสำคัญตอนนี้? เพราะเส้นตายทางกฎหมายกำลังมา:

วันที่	เกิดอะไรขึ้น
11 ก.ย. 2026	EU CRA (Cyber Resilience Act) บังคับใช้ภาระการรายงาน — แจ้งเตือน 24 ชม. / แจ้งเต็ม 72 ชม. เมื่อเจอช่องโหว่ที่ถูกโจมตีจริง
21 ก.ย. 2026	ใบรับรอง FIPS 140-2 ย้ายเข้า "Historical List" — ใช้ต่อได้แต่ justify การจัดซื้อภาครัฐใหม่ไม่ได้
1 ม.ค. 2027	CNSA 2.0 กลายเป็นค่าเริ่มต้นสำหรับงาน NSS ของสหรัฐฯ
11 ธ.ค. 2027	ข้อกำหนดสำคัญของ CRA รวมถึง mandate เรื่อง machine-readable SBOM

พูดง่าย ๆ: ถ้าสินค้าคุณต้องผ่าน compliance พวกนี้ คุณต้องพิสูจน์ได้ว่าโค้ดทุกบรรทัดมาจากไหน — และสำหรับโค้ดที่ "แปล" มาจากที่อื่น การพิสูจน์นั้นต้องลงถึงระดับฟังก์ชัน ไม่ใช่ระดับ build

นี่คือเหตุผลที่ Goish เกิด

ใช้เทคนิคอะไรบ้าง

ส่วนนี้คือความเจ๋งทางวิศวกรรม — ถ้าไม่อยากอ่านเชิงลึก ข้ามไปหัวข้อถัดไปได้เลย

1. M:N Scheduler — พอร์ตแบบ verbatim จาก `runtime/proc.go`

Goish ไม่ได้ "เขียน scheduler ใหม่ให้คล้าย Go" — มันแปล runtime/proc.go ของ Go 1.25 มาทีละบรรทัด:

Per-P run queue แบบ lock-free SPMC (256 entry) + global overflow
Work stealing แบบ coprime-permuted (runqgrab / runqsteal / stealOrder)
Async preemption ผ่าน SIGURG (เทคนิคเดียวกับที่ Go ใช้หยุด goroutine ที่รันนานเกิน)
sysmon ตัวจัดการ timer heap + force-preempt
epoll netpoller แบบ per-P (โมเดลเดียวกับ nginx) — เวลา goroutine รอ I/O มันจะ park goroutine ไม่ใช่ block thread

2. Memory: page allocator + 67 size classes (แต่ไม่มี GC)

Goish เอาโครงสร้าง allocator ของ Go (mheap → mcentral → per-P mcache, 67 size classes) มาใช้ แต่ตัด garbage collector ออก — ให้ Rust ownership เป็นคน reclaim แทน

สำหรับ stack ของ goroutine มันใช้วิธีฉลาด: goroutine หนึ่งตัวได้ virtual reservation 1 MiB แบบ lazy-commit (kernel ค่อย commit หน้า 4 KiB เมื่อถูกแตะจริง) — แปลว่า goroutine ที่ทำงานตื้น ๆ เสีย memory จริงแค่ประมาณหนึ่ง page และถ้าอยากได้ความหนาแน่นสุดขีด ก็ใช้ go!(stack(2*KB), …) เพื่อขอ stack ขนาด 2 KiB จาก stack pool

ผลลัพธ์ตาม demo:

ts  vmsize_kb  vmrss_kb  vmpeak_kb  vmhwm_kb  threads
 0s    1105148      44800    1108444      49024   13   ← baseline
 2s    3069660    2406528    3069660    2406528   13   ← 1M parked
30s    3069660    2406528    3069660    2406528   13   ← steady-state

goroutine หนึ่งล้านตัว บน OS thread แค่ 13 เธรด — ~2.4 KiB RSS ต่อ goroutine

3. เขียนโค้ดที่ "อ่านแล้วเหมือน Go" แต่ compile ด้วย rustc

จุดเด่นที่สุดสำหรับคนเขียน Go — public API ใช้ type ตัวพิมพ์เล็กแบบ Go แทน type ของ Rust:

fn get(url: string) -> (int, string, string) {
    let (mut resp, err) = http::Get(url.clone());
    if err != nil {
        return (-1, fmt::Sprintf!("get %s: %v", url, err), string(""));
    }
    let (body, _) = io::ReadAll(&mut resp.Body);
    let _ = io::Closer::Close(&mut resp.Body);
    return (resp.StatusCode, string(body), resp.Header.Get("Content-Type"));
}

string, int, multi-return, if err != nil — ทั้งหมดคือ Rust จริง ๆ ที่ rustc compile ได้ แต่อ่านแล้วแทบไม่ต่างจาก Go และ Vec<u8> กับ &str ไม่โผล่ใน signature สาธารณะเลย

นี่คือ philosophy หลัก: "Port first, get idiomatic later" — พอร์ตโค้ด Go มาแบบเกือบ line-by-line ก่อน แล้วค่อย ๆ ปรับเป็น Rust idiom ทีละ module เมื่อทีมพร้อม

4. crypto/tls — พอร์ตครบ 100% พร้อมใบเสร็จทุกบรรทัด

ส่วนที่ภาคภูมิใจที่สุดคือ crypto/ — ครบ 1722/1722 declarations (100%) ทั้ง 66 packages รวมถึง crypto/internal/fips140* ทั้ง 35 packages ที่เป็น code path ของ FIPS validation และ net/http ครบ 639/639 functions (100%)

TLS 1.3 ที่รันจริงคือ crypto/tls ที่ port มา verbatim — ไม่ใช่ implementation ใหม่ที่เขียนเลียนแบบ

ประโยชน์ที่ได้

Binary เดียว ไม่มี libc ไม่มี ld.so — ลด attack surface เหลือแค่ตัว binary เอง เหมาะกับ scratch/distroless container, confidential VM, appliance image
Memory safety + concurrency model ของ Go — ได้ ownership ของ Rust (ไม่มี dangling pointer, ไม่มี data race) กับ goroutine/channel/select ของ Go ในตัวเดียว
Provenance ถึงระดับฟังก์ชัน — พิสูจน์ compliance (EU CRA, FIPS, CNSA) ได้ เพราะทุกฟังก์ชันมีที่มาอ้างอิง
ไม่มี GC ให้ tune — ไม่มี stop-the-world ไม่มี GC pause
เส้นทาง migrate จาก Go → Rust แบบค่อยเป็นค่อยไป — ไม่ต้องหยุดทุกอย่างเพื่อ rewrite ใหม่หมด

วิธีเริ่มต้น

ต้องการแค่ Rust 1.79+ และ Linux x86_64 (single-target ณ ตอนนี้)

git clone https://github.com/cogentica-ai/goish
cd goish

# build library
cargo build --target x86_64-unknown-linux-gnu --release

# demo: หนึ่งล้าน goroutine
cargo build --target x86_64-unknown-linux-gnu --release --example spawn_million
./examples/spawn_million.sh

# goginx: nginx clone ที่เขียนด้วย goish
cargo build --target x86_64-unknown-linux-gnu --release --example goginx

โค้ด "Hello" แบบ Goish หน้าตาประมาณนี้:

use goish::{fmt, go};

#[goish::main]
fn main() {
    go!(move || {
        fmt::Println!("hello from a goroutine");
    });
}

ข้อจำกัด (บอกตรง ๆ)

ยังไม่ใช่ Go compiler — คุณเขียน Rust ที่อ่านเหมือน Go ไม่ได้ compile ไฟล์ .go
Linux x86_64 เท่านั้น — target อื่นยังไม่อยู่ใน scope
ยังไม่ผ่าน security audit — TLS stack port มาแบบ machine-checked แต่ยังไม่มี external review (ดู SECURITY.md ก่อนใช้จริง)
ยัง port ไม่ครบทั้ง Go — crypto/ กับ net/http เสร็จแล้ว แต่ net, encoding, os ยังบางส่วน

สรุป

Goish ไม่ได้เป็นแค่ "Go runtime ใน Rust" — มันเป็นความพยายามตอบคำถามที่ใหญ่กว่านั้น: เมื่อเราต้องย้ายภาษาในโลกที่มีกฎหมายบังคับเรื่องที่มาของโค้ด เราจะพิสูจน์ได้ยังไงว่าโค้ดทุกบรรทัดไว้ใจได้

คำตอบของ Chanwit คือการพอร์ต Go แบบมี "ใบเสร็จ" ทุกบรรทัด แล้วเอา ownership ของ Rust มาแทน GC — ได้ทั้งความคุ้นเคยของ Go, ความปลอดภัยของ Rust, และหลักฐาน compliance ที่ตรวจซ้ำได้

โปรเจกต์นี้เพิ่งเปิด (สิงหาคม 2026) และยังพัฒนาอย่างต่อเนื่อง ถ้าสนใจเข้าไปดูได้ที่:

🌐 https://goish.cogentica.ai
💻 https://github.com/cogentica-ai/goish

เครดิต: บทความนี้อ้างอิงข้อมูลจากเว็บไซต์ goish.cogentica.ai และ README ของ github.com/cogentica-ai/goish — โปรเจกต์โดย Chanwit Kaewkasi (@chanwit) ภายใต้ Cogentica AI (ประเทศไทย)

⚠️ Goish ไม่เกี่ยวข้องกับ Google หรือ Go project — "Go" เป็นเครื่องหมายการค้าของ Google LLC

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

DEV Community: Gophernment

tmux: เปลี่ยน terminal จอเดียวให้เป็นหลายจอ งานยาว ๆ ก็ไม่หายเมื่อ SSH หลุด

เรื่องเริ่มจาก SSH หลุดกลางคัน

tmux คืออะไร กันแน่

session, window, pane — สามชั้นที่ซ้อนกัน

คำสั่งพื้นฐานที่ใช้จริงทุกวัน

เริ่ม session แรก

ปุ่ม "เรียก" ที่ชื่อ prefix

สถานการณ์จริง: งานยาว + จอแบ่งครึ่ง

1. SSH รันงานยาว แล้วเดินออกจากจอได้สบาย ๆ

2. จอเดียว เห็นทั้งโค้ด ทั้ง log

ปรับ .tmux.conf ให้เข้ากับมือ

สรุป: เริ่มจาก session เดียวก่อน

Generic methods ใน Go 1.27: ฟีเจอร์ที่เคยถูกบอกว่า "ไม่มีทาง" แต่ community ผลักดันจนสำเร็จ

เกริ่น: Go 1.18 เปิดตัว generics แต่ทิ้งช่องว่างไว้

Generic methods คืออะไร

ทำไมตอน 1.18 ถึงข้ามไป

แล้ว community เปลี่ยนเกมยังไง

ข้อจำกัดที่ยังเหลือ (สำคัญ)

สรุป

แหล่งอ้างอิง

Aider: AI pair programming ใน terminal — เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

Aider คืออะไร

เริ่มใช้งานง่าย ๆ

จุดเด่นของ Aider

ข้อควรรู้ก่อนใช้จริง

เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

เลือกยังไง

แหล่งอ้างอิง

AI เขียน Go โบราณตลอด — JetBrains เลยทำ "กติกาการเขียน Go สมัยใหม่" ให้ agent แล้ว

ทำไม AI ถึงเขียน Go เก่า ทั้งที่ Go ออกฟีเจอร์ใหม่ตลอด

แล้ว JetBrains แก้ยังไง

ข้างในมีอะไรน่าสนใจบ้าง

min / max แทนการเทียบเอง (Go 1.21)

slices.Contains แทน loop หา (Go 1.21)

for i := range n แทนการนับเอง (Go 1.22)

errors.AsType แทน errors.As แบบเก่า (Go 1.26)

ลองใช้ดู

สรุป

แหล่งอ้างอิง

จาก Vibe Coding สู่ Agentic Engineering — SDLC ใหม่ที่กำลังมาแทนที่

"vibe coding" คำนี้มาจากไหน

เส้นแบ่งจริง ๆ ไม่ใช่ "ใช้ AI หรือไม่" แต่อยู่ที่ "ตรวจสอบแค่ไหน"

ทักษะที่แท้จริงไม่ใช่ "prompt" แต่เป็น "context"

model ไม่ใช่ทุกอย่าง — แนวคิด Harness ที่คนส่วนใหญ่เข้าใจผิด

ปัญหา 80% — ทำไม AI ยังแทนเราไม่ได้ (และก็ไม่ควร)

เงินที่ซ่อนอยู่ใต้ vibe coding

แล้วควรเริ่มยังไง

ทิ้งท้าย

Goish: พอร์ตรันไทม์ของ Go ทั้งตัวลงใน no_std Rust

Goish คืออะไร

ทำไมถึงคิดทำตัวนี้ (ที่มาที่ไป)

ใช้เทคนิคอะไรบ้าง

1. M:N Scheduler — พอร์ตแบบ verbatim จาก runtime/proc.go

2. Memory: page allocator + 67 size classes (แต่ไม่มี GC)

3. เขียนโค้ดที่ "อ่านแล้วเหมือน Go" แต่ compile ด้วย rustc

4. crypto/tls — พอร์ตครบ 100% พร้อมใบเสร็จทุกบรรทัด

ประโยชน์ที่ได้

วิธีเริ่มต้น

ข้อจำกัด (บอกตรง ๆ)

สรุป

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

READ → EVAL → PRINT → LOOP

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

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

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

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

1960s — LISP

1990–1991 — Python

1995 — Ruby IRB

2006 — Firebug

2009 — Node.js REPL

2011 — Chrome DevTools Console

2014 — IPython / Jupyter Notebook

2015 — Rust Playground

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

อ่านเพิ่ม

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

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

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

`min` / `max` แทนการเทียบเอง (Go 1.21)

`slices.Contains` แทน loop หา (Go 1.21)

`for i := range n` แทนการนับเอง (Go 1.22)

`errors.AsType` แทน `errors.As` แบบเก่า (Go 1.26)

1. M:N Scheduler — พอร์ตแบบ verbatim จาก `runtime/proc.go`

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