DEV Community: Gophernment

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

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

Gophernment — Thu, 09 Jul 2026 13:01:46 +0000

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

เคยเปิด log ใน production แล้วเจอแบบนี้ไหม:

INFO  request received
INFO  processing...
INFO  done

สามบรรทัดนี้ — บอกอะไรเราไม่ได้เลย — request ไหน? ใช้เวลากี่ ms? สำเร็จหรือพัง?

หรืออีกแบบ — log ทุกอย่าง:

DEBUG user_id=42 name=สมชาย email=somchai@email.com 
       credit_card=4111-xxxx-xxxx-1234 amount=1500

PII เต็ม log — GDPR ปรับเป็นล้าน — และ storage ก็ไม่ฟรี

การ log ใน microservice ไม่ใช่แค่ "ใส่ print เยอะ ๆ" — มันคือการตัดสินใจว่า อะไรควรเก็บ อะไรไม่ควรเก็บ — และบทความนี้จะว่ากันทีละเรื่อง

ข้อมูลพื้นฐานที่ทุก log ควรมี

ไม่ว่าจะเป็น service อะไร — log ทุกบรรทัดควรมี 5 สิ่งนี้:

ts=2026-07-09T03:15:30Z level=INFO 
  msg="order created" trace_id=abc123 span_id=def456
  service=order-svc user_id=42 duration_ms=120

ต้องมี	ตัวอย่าง	ทำไม
timestamp	`ts=2026-07-09T03:15:30Z`	รู้ว่าเกิดเมื่อไหร่ — ISO 8601, UTC เสมอ
level	`level=INFO`	กรองได้ — DEBUG/INFO/WARN/ERROR
message	`msg="order created"`	คนอ่านรู้ว่าเกิดอะไรขึ้น — สั้น กระชับ
trace_id	`trace_id=abc123`	ตาม request นี้ข้าม service ได้
service	`service=order-svc`	รู้ว่า log มาจาก service ไหน

trace_id — สำคัญที่สุด

ถ้าจะเลือกทำแค่ 1 อย่าง — ทำ trace_id — เพราะมันเชื่อม log ของทุก service ที่ request นี้ผ่าน

อย่า reinvent เอง — ใช้ W3C Trace Context (traceparent header):

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
              │  │                                      │              │
              ver trace_id                               span_id        flags

นี่คือมาตรฐานที่ Jaeger, Datadog, Tempo, Grafana รองรับทั้งหมด — ไม่ต้อง generate เอง ไม่ต้อง invent header เอง

import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/propagation"
)

// middleware — extract trace_id จาก W3C traceparent header
// suboptimal: อ่าน trace_id ได้ถูก แต่ไม่ได้สร้าง span (ไม่มี duration/status)
// production ควรใช้ otelhttp.NewHandler(mux, "order-service") จาก otelcontrib
func TracingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        propagator := propagation.TraceContext{}
        ctx := propagator.Extract(r.Context(), propagation.HeaderCarrier(r.Header))
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// ใน handler — trace_id ได้จาก span โดยตรง ไม่ต้อง context.WithValue
func (h *Handler) GetOrder(w http.ResponseWriter, r *http.Request) {
    span := trace.SpanFromContext(r.Context())
    traceID := span.SpanContext().TraceID().String()

    slog.InfoContext(r.Context(), "order fetched",
        slog.String("trace_id", traceID),  // ← ได้ฟรีจาก OTel
        slog.String("order_id", orderID),
    )
}

ข้อดีของวิธีนี้: ไม่มี custom header, ไม่มี context.WithValue string key, trace_id ตามข้าม service ได้อัตโนมัติผ่าน HTTP propagation — ทุก tool ใน ecosystem รองรับ

log เมื่อไหร่ — 3 จุดที่ควร log + 1 จุดที่ต้องคิดให้ดี

1. Error — log ทุกครั้งเสมอ

ไม่มีข้อแม้ — error ต้องมี log:

if err != nil {
    slog.ErrorContext(ctx, "database query failed",
        slog.String("query", "INSERT INTO orders"),
        slog.String("error", err.Error()),
        slog.String("user_id", userID),
    )
}

ไม่ควร log แบบนี้:

slog.Error("error", err)  // ❌ ไม่มี context — อ่านไม่รู้เรื่อง

2. Call external service

ทุกครั้งที่เรียก service อื่น หรือ external API:

func (s *Service) notifyWarehouse(ctx context.Context, order *Order) error {
    start := time.Now()
    err := s.warehouseClient.Notify(ctx, order)

    slog.InfoContext(ctx, "warehouse notification",
        slog.String("target", "warehouse-svc"),
        slog.String("order_id", order.ID),
        slog.Int64("duration_ms", time.Since(start).Milliseconds()),
        slog.Bool("success", err == nil),
    )
    return err
}

3. Business event

สิ่งที่เกิดขึ้นแล้วมีผลทางธุรกิจ — log ทุกครั้ง:

slog.InfoContext(ctx, "order paid",
    slog.String("event", "payment_completed"),
    slog.String("order_id", order.ID),
    slog.Float64("amount", order.Amount),
)

4. Request/Response — ไม่จำเป็นต้อง log ทุก service

ข้อนี้ต้องแยกให้ดี — log ทุก request ในทุก service = storage พุ่งแน่

ตัวอย่าง — 20 services, 1,000 req/s, แต่ละ request ผ่าน 5 services:

ถ้า log ทุก request ในทุก service:
  INFO request → 5 services × 1,000 req/s = 5,000 log lines/วินาที
  ต่อวัน = 432 ล้านบรรทัด
  ต่อเดือน = 13 พันล้านบรรทัด → storage เป็น TB

minimum requirement ที่พอดี:

✅ log ที่ API Gateway (entry point) เท่านั้น:
   INFO request method=POST path=/orders trace_id=abc123

❌ log ทุก service ที่ request ผ่าน:
   INFO order-svc: request received   ← ไม่จำเป็น
   INFO payment-svc: request received ← ไม่จำเป็น
   INFO inventory-svc: request received ← ไม่จำเป็น

✅ ใช้ tracing แทน:
   trace_id=abc123 → ตามดูทุก service ได้ โดยไม่ต้อง log

ถ้าอยากรู้ว่า request ผ่าน service ไหนบ้าง — tracing คือคำตอบ — ถูกกว่าและข้อมูลมากกว่า:

// tracing — ถูกกว่า log ตรงที่:
// 1. sampling ได้ (10% แทน 100%)
// 2. ข้อมูลดีกว่า — เห็น parent-child relationship
// 3. storage มักถูกกว่า (compressed binary แทน text)

func CreateOrder(ctx context.Context) {
    ctx, span := tracer.Start(ctx, "CreateOrder")
    defer span.End()
    // ... business logic
}

สรุปเรื่อง request/response:

ที่ไหน	log request?	เพราะ
API Gateway	✅ ควร	รู้ว่ามี request อะไรเข้ามา — แค่นี้ก็พอ
Internal service	❌ ไม่ควร	ใช้ tracing แทน — ถูกกว่า
Error	✅ ทุกที่	error ต้อง log เสมอ
Business event	✅ ทุกที่	นี่คือสิ่งที่ stakeholders สนใจ

อย่าสับสน — บทความนี้ไม่ได้บอกว่า "อย่า log"

กำลังบอกว่า อย่า log request ในทุก service — เพราะมันเปลือง storage โดยไม่จำเป็น — ใช้ tracing แทน

แต่ ERROR, business event, call external — log ได้เลย ไม่ต้องคิดมาก

Structured Logging — log แบบให้เครื่องอ่านรู้เรื่อง

ใช้ slog (Go 1.21+) — text format สำหรับ dev, JSON format สำหรับ production:

// development — text format (อ่านง่าย)
logger := slog.New(slog.NewTextHandler(os.Stdout, nil))
// ts=2026-07-09T03:15:30Z level=INFO msg="order created" order_id=ORD-001

// production — JSON format (เอาเข้า Grafana/Loki/Datadog)
logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
// {"ts":"2026-07-09T03:15:30Z","level":"INFO","msg":"order created","order_id":"ORD-001"}

ข้อดีของ structured log:

search ด้วย field ได้ — level=ERROR AND service=payment
aggregate ได้ — นับ orders/ชม
alert ได้ — ERROR > 10 ใน 5 นาที → pager

Business Log — log เพื่อธุรกิจ ไม่ใช่เพื่อ debug

นอกจาก log ทางเทคนิค — ควรมี log ที่ตอบคำถามทางธุรกิจ:

คำถาม	log แบบไหน
"วันนี้ขายได้เท่าไหร่?"	`event=order_paid amount=1500`
"feature ใหม่มีคนใช้ไหม?"	`event=feature_used feature=new_search`
"ลูกค้าหลุดตอนขั้นตอนไหน?"	`event=checkout_abandoned step=payment`
"ของใกล้หมดไหม?"	`event=stock_low sku=BKK-001 remaining=3`

เทคนิค: ใส่ event= prefix — ทำให้ search ใน log ง่าย:

slog.InfoContext(ctx, "user action",
    slog.String("event", "checkout_completed"),  // ← search ด้วยคำนี้
    slog.String("user_id", userID),
    slog.Float64("total", total),
    slog.Int("items", len(cart.Items)),
)

PII — สิ่งที่ห้าม log เด็ดขาด

PII (Personally Identifiable Information) คือข้อมูลที่ระบุตัวบุคคลได้ — และมันมีกฏหมายควบคุม (GDPR, PDPA)

❌ ห้าม log	✅ log แบบนี้แทน
`email=somchai@email.com`	❌ อย่า log — ใช้ `user_id=42` แทน การ hash email แบบ plain SHA256 ไม่ปลอดภัย — email space มันจำกัด โดน rainbow table / brute force ง่าย — ต้องใช้ HMAC-SHA256 with secret key เท่านั้น ซึ่งยุ่งยากเกินเหตุ — user_id ก็พอแล้ว
`credit_card=4111-xxxx`	`payment_method=credit_card last_four=1234`
`password=secret123`	❌ ไม่มีเหตุผลที่ต้อง log เลย
`ssn=123-45-6789`	❌ ไม่มีเหตุผล — ใช้ user_id แทน
`phone=0812345678`	❌ อย่า log — hash plain SHA256 ก็ไม่ปลอดภัยด้วยเหตุผลเดียวกับ email — ไม่เก็บเลยดีที่สุด
`address=123 ถนนสุขุมวิท`	`province=กรุงเทพ` (เอาแค่ระดับจังหวัด)
`ip=192.168.1.1`	❌ อย่า log — แม้ mask เหลือ `192.168..` ก็ยังเป็น PII ภายใต้ GDPR — ถ้าไม่ได้ใช้ทำ security/geo-block จริงจัง ไม่ต้องเก็บ
`full_name=สมชาย ใจดี`	`user_id=42`

วิธีป้องกัน — ทำที่ middleware

func SanitizeLog(record slog.Record) slog.Record {
    // strip PII fields ก่อน log
    record.Attrs(func(a slog.Attr) bool {
        if a.Key == "email" || a.Key == "password" || 
           a.Key == "credit_card" || a.Key == "ssn" {
            return false  // ไม่ log field นี้
        }
        return true
    })
    return record
}

กฏง่าย ๆ: ถ้าคิดว่า "log นี้จะถูกอ่านโดยคนนอกบริษัท" — ข้อมูลนั้นไม่ควรอยู่ใน log

log level — เมื่อไหร่ใช้อะไร

Level	เมื่อไหร่	ตัวอย่าง
DEBUG	ระหว่าง dev — production ปิด	`DEBUG query params: {...}`
INFO	business event, request flow ปกติ	`INFO order paid amount=1500`
WARN	สิ่งที่ไม่ควรเกิด แต่ไม่พัง	`WARN retry 3/5 connection refused`
ERROR	สิ่งที่พัง — ต้องมีคนดู	`ERROR payment failed order_id=001`
FATAL	service หยุดทำงาน	`FATAL cannot connect to database`

💡 อย่าใช้ ERROR สำหรับสิ่งที่คาดเดาได้ — user not found = INFO (ไม่ใช่ ERROR ไม่ใช่ WARN) — เพราะมันคือ expected client error เกิดถี่มาก (login attempt ผิด, search ไม่เจอ) ถ้าเป็น WARN จะ pollute alert threshold — สงวน WARN ไว้กับ signal ที่ operator ต้องสนใจจริง (retry, degraded, near-limit) เท่านั้น

ตัวอย่าง — log ใน service จริง

func (s *OrderService) Checkout(ctx context.Context, req *CheckoutReq) (*Order, error) {
    // 1. business validation — INFO เพราะเป็น expected client error
    if req.Total <= 0 {
        slog.InfoContext(ctx, "invalid checkout amount",
            slog.Float64("total", req.Total),
        )
        return nil, ErrInvalidAmount
    }

    // 2. call external — log duration + success
    start := time.Now()
    paid, err := s.payment.Charge(ctx, req)
    slog.InfoContext(ctx, "payment processed",
        slog.Float64("amount", req.Total),
        slog.Int64("duration_ms", time.Since(start).Milliseconds()),
        slog.Bool("success", err == nil),
    )
    if err != nil {
        slog.ErrorContext(ctx, "payment failed",
            slog.String("error", err.Error()),
            slog.Float64("amount", req.Total),
        )
        return nil, err
    }

    // 3. business event — event= สำหรับ search
    slog.InfoContext(ctx, "order completed",
        slog.String("event", "checkout_completed"),
        slog.String("order_id", paid.OrderID),
        slog.Float64("amount", req.Total),
        slog.Int64("duration_ms", time.Since(start).Milliseconds()),
    )

    return paid.Order, nil
}

จุดที่มักถูกมองข้าม

timestamp ต้องเป็น UTC เสมอ ไม่ใช่ local time

distributed system มี server หลาย timezone — ถ้า log A ใช้ +07:00 log B ใช้ +00:00 — sort log ข้าม service พังทันที

// ❌ local time — sort ข้าม service ไม่ได้
slog.Info("order created", "ts", time.Now())

// ✅ UTC เสมอ + มี NTP sync ทุกเครื่อง
slog.Info("order created", "ts", time.Now().UTC())

ทุกเครื่องใน cluster ต้อง sync NTP — clock skew แค่ 5 วิ ก็ทำให้ trace ดูไม่ออกว่า A เกิดก่อน B หรือเปล่า

log ต้อง correlate กับ trace — ไม่ใช่แยกกัน

บทความพูดถึง slog กับ OTel แยกกัน — แต่ใน production ควร integrate ให้มันเป็นเรื่องเดียวกัน:

// ✅ log มี trace_id + span_id — คลิกจาก Grafana ไปดู log ได้
span := trace.SpanFromContext(ctx)
slog.InfoContext(ctx, "order paid",
    slog.String("trace_id", span.SpanContext().TraceID().String()),
    slog.String("span_id", span.SpanContext().SpanID().String()),
)

ถ้า trace_id ใน log ตรงกับ trace_id ใน tracing backend — คุณคลิกจาก dashboard ไปดู log ของ request นั้นได้ทันที

ป้องกัน log injection

user input มี \n หรือ ANSI escape — inject เข้า log ได้:

// ❌ user input เข้า log โดยตรง — attacker ใส่ \n → ปลอมแปลง log entry
slog.Info("user search", slog.String("q", r.URL.Query().Get("q")))

// q=hello\n2026-07-09T10:00:00Z INFO admin logged in  ← ปลอม!

// ✅ sanitize ก่อน log
import "strconv"
q := strconv.Quote(r.URL.Query().Get("q"))  // escape \n, \t, control chars
slog.Info("user search", slog.String("q", q))

error log ที่จุดเดียว — จุดสูงสุดของ call chain

error bubble ผ่าน 3 layers แล้ว log ทุกชั้น = duplicate stack trace:

// ❌ log error ซ้ำทุก layer (pseudocode — ฟังก์ชันจริง syntax จะสมบูรณ์กว่านี้)
func repo.FindByID()  { log.Error(err); return err }
func svc.GetUser()    { log.Error(err); return err }
func handler.GetUser(){ log.Error(err); return err }
// → 3 log lines สำหรับ 1 error

// ✅ log ที่ top-level handler — จุดเดียว
func repo.FindByID()  { return fmt.Errorf("FindByID: %w", err) }
func svc.GetUser()    { return fmt.Errorf("GetUser: %w", err) }
func handler.GetUser(){ slog.Error("failed", "error", err) }
// → 1 log line — ครอบคลุมทั้ง chain (ผ่าน %w)

business event = metric + log — ไม่ใช่แค่ log

order paid amount=1500 — เก็บเป็น log อย่างเดียวไม่พอ:

// ✅ counter (low-cardinality labels เท่านั้น) + histogram (สำหรับ value ต่อเนื่อง)
orderCounter.Add(ctx, 1, metric.WithAttributes(
    attribute.String("event", "payment_completed"),
    attribute.String("currency", "THB"),          // ← low-cardinality OK
    // ❌ ห้ามใช้ attribute.Float64("amount", amount) — cardinality ระเบิด!
    // แต่ละ order มี amount ไม่ซ้ำกัน → timeseries ใหม่ทุก order → Prometheus พัง
))
paymentAmountHistogram.Record(ctx, amount)        // ← ใช้ Histogram สำหรับ value ต่อเนื่อง
slog.InfoContext(ctx, "order paid", ...)

⚠️ Metric cardinality คือ mistake ที่พบบ่อยที่สุด: ห้ามใช้ value ที่มี unique สูง (order_id, amount, email) เป็น label บน counter — ต้องใช้ Histogram/Gauge แทน มิฉะนั้น Prometheus/OTel backend จะ memory ระเบิดจาก timeseries เป็นล้าน ๆ series

rate-limit log — retry storm ต้องไม่ฆ่า storage

circuit breaker fail → WARN ทุก 100ms → 36,000 log lines/ชม:

import "golang.org/x/time/rate"

// keyed limiter — แต่ละ error type มี limiter ของตัวเอง
// ไม่งั้น db timeout จะบัง cache miss
var limiters sync.Map // map[string]*rate.Limiter

func warnWithLimit(ctx context.Context, msg string, args ...any) {
    lim, _ := limiters.LoadOrStore(msg, rate.NewLimiter(rate.Every(5*time.Second), 1))
    if lim.(*rate.Limiter).Allow() {
        slog.WarnContext(ctx, msg, args...)
    }
}

dynamic log level — debug production โดยไม่ deploy

เปลี่ยน log level เป็น DEBUG ตอน runtime:

var globalLevel = new(slog.LevelVar)  // ← mutable
logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
    Level: globalLevel,
}))

// HTTP endpoint สำหรับเปลี่ยน level — ต้องอยู่หลัง internal-only network/mTLS/auth middleware
// ❌ ห้ามเปิด public — DEBUG level จะ leak sensitive data + เป็น DoS vector
mux := http.NewServeMux()
mux.HandleFunc("/debug/loglevel", authMiddleware(func(w http.ResponseWriter, r *http.Request) {
    level := r.URL.Query().Get("level")  // debug, info, warn, error
    globalLevel.Set(parseLevel(level))
}))

# debug production incident — เปลี่ยน level ชั่วคราว
curl -X POST "http://payment-svc:8080/debug/loglevel?level=debug"
# แก้เสร็จ → กลับมา info
curl -X POST "http://payment-svc:8080/debug/loglevel?level=info"

retention tiering — hot → cold → delete

hot (7 วัน, SSD): Loki/Grafana Cloud → fast search
warm (30 วัน, HDD): S3 Standard → search ได้แต่ช้า
cold (90 วัน, Glacier): S3 Glacier → ต้อง restore ก่อน
delete (>90 วัน): ไม่เก็บ

policy นี้สำคัญกว่าแค่รู้ว่า "storage แพง" — ต้องมี tier จริง

JSON log กับ multiline — ต้อง escape

stack trace มี \n — JSON parser พังถ้าไม่ escape:

// ❌ JSON log — stack trace ทำ JSON แตก
{"msg": "panic: runtime error\n\ngoroutine 1 [running]:\n..."}

// ✅ ใช้ json.Marshal หรือ slog.Attr
slog.Error("panic", slog.String("stack", string(debug.Stack())))
// slog จัดการ escape \n → \\n ให้อัตโนมัติ

access log ≠ application log

"log เฉพาะที่ API Gateway" — หมายถึง application log (ที่ dev เขียนเอง) — แต่ access log เป็นคนละเรื่อง:

	Access Log	Application Log
ใครเขียน	infra (nginx, envoy, load balancer)	dev (ในโค้ด)
เก็บอะไร	method, path, status, latency, IP	business event, error, debug
volume	มหาศาล (ทุก request)	น้อยกว่า (เฉพาะที่สำคัญ)
cost	ต่ำ — infra-level, compressed binary	ปานกลาง — JSON text
ทำไมต้องมี	security audit, traffic analysis	debug, business analytics

หลาย org เก็บ access log ทุก ingress — แต่นั่นเป็น infra-layer ไม่ใช่ application code — และ cost structure ต่างกันกับที่บทความคำนวณ

สรุป — checklist

✅ ทุก log มี: timestamp (UTC), level, message, trace_id + span_id
✅ log: error (ที่ top-level), call external, business event
✅ structured log (JSON) ใน production
✅ business event = metric (Prometheus) + log — ไม่ใช่แค่ log
✅ PII — ไม่ต้อง hash เพราะ hash plain SHA256 ไม่ปลอดภัย — ไม่ log เลย
✅ ใช้ log level ให้ถูก — user not found = INFO ไม่ใช่ WARN
✅ rate-limit WARN/ERROR — retry storm ต้องไม่ระเบิด storage
✅ dynamic log level — เปลี่ยน runtime โดยไม่ deploy
✅ sanitize user input ก่อน log — กัน log injection (\n, ANSI escape)
✅ retention: hot 7d → warm 30d → cold 90d → delete
✅ access log (infra) ≠ application log — cost structure ต่างกัน
✅ NTP sync ทุกเครื่อง — clock skew >5 วิ = sort log ข้าม service พัง

📚 อ่านต่อ:

slog package — Go 1.21+ structured logging

OpenTelemetry Go — tracing + logging

GDPR & logging — ข้อกำหนด PII

microservice ต้องมี observability แค่ไหน ถึงจะคุ้ม

Gophernment — Wed, 08 Jul 2026 23:39:09 +0000

microservice ต้องมี observability แค่ไหน ถึงจะคุ้ม

มีเรื่องเล่าในทีมที่ผมเคยทำงานด้วย:

ระบบล่มตอนตี 2 — pager ดัง — dev ตื่นมาเปิด laptop
ใช้เวลา 45 นาทีแกะว่า error เกิดจาก service ไหน
พอรู้ว่าเป็น payment-service — ใช้เวลาอีก 20 นาทีไล่ว่า request นี้ผ่าน auth-service → order-service → payment-service → แล้วพังที่ payment-service เพราะ inventory-service ตอบกลับมา 500

1 ชั่วโมง 5 นาที — เพื่อรู้ว่า "พังที่ inventory"

ถ้ามี tracing — รู้ใน 2 นาที

นี่คือเหตุผลที่ observability เกิด — แต่มันก็มีราคาที่ต้องจ่าย

observability คืออะไร

ไม่ใช่แค่ monitoring — monitoring บอกว่า "CPU 90%" — observability บอกว่า "CPU 90% เพราะเมื่อกี้มี request จาก order-service มา 10,000 requests ใน 1 นาที — และ 30% ของ requests พังที่ SELECT * FROM orders WHERE..."

3 เสาหลัก:

	ถามอะไร	ตัวอย่าง
📊 Metrics	"เกิดอะไรขึ้น?"	CPU 90%, latency 2s, error rate 5%
📜 Logs	"เกิดเพราะอะไร?"	`EROR: connection refused dial tcp 10.0.1.5:5432`
🔍 Traces	"ผ่านมาทางไหน?"	`gateway → auth → order → payment → inventory`

monitoring = metrics — รู้ว่ามีปัญหา
observability = metrics + logs + traces — รู้ว่าปัญหาคืออะไร และเกิดที่ไหน

ทำไม microservice ถึงต้องการ observability มากกว่า monolith

เพราะ request เดียวผ่าน service เยอะ

Monolith:
  request → [app] → response
  log อยู่ที่เดียว — เปิดไฟล์เดียวเจอ

Microservice:
  request → gateway → auth → user → order → payment → inventory → ...
  log กระจาย 7 services — ไม่มีทางไล่เองไหว

จำนวน service กับเวลา debug:

จำนวน service	เวลาที่ใช้แกะว่า error อยู่ตรงไหน (เฉลี่ย)
1 (monolith)	5-10 นาที
5	15-30 นาที
10	30-60 นาที
20+	"ขอไปชงกาแฟก่อน"

นี่คือ exponential growth ของความซับซ้อน — ไม่ใช่ linear

เพราะไม่มีใคร "เห็นภาพรวม"

dev-A: "ผมดู log ของ payment-service แล้ว — มันพังที่ call external API"
dev-B: "แต่ external API มันรับ request จาก payment-service ปกตินะ"
dev-C: "เดี๋ยวนะ — payment-service ใช้ connection pool เก่าที่ถูก reset โดย auth-service"

ทุกคนเห็นแค่สิ่งที่ตัวเองดูแล — ไม่มีใครเห็น flow ทั้งหมด — tracing คือเครื่องมือเดียวที่แก้ปัญหานี้ได้

ต้องแลกด้วยอะไร

เงิน

Datadog ทีม 20 services: ~$2,500/เดือน
Grafana self-host: ~$250/เดือน + engineer time

แต่เงินไม่ใช่ต้นทุนเดียว

เวลาตั้งค่า — และ maintain

สิ่งที่ต้องทำ:
1. ติดตั้ง OpenTelemetry SDK ในทุก service
2. ตั้งค่า collector — รับ data → ส่งไป backend
3. ตั้งค่า backend — Grafana/Prometheus/Datadog
4. สร้าง dashboard — อันนี้ใช้เวลาเยอะที่สุด
5. ตั้ง alert — ไม่งั้นมี dashboard แต่ไม่มีใครดู
6. onboard ทีม — สอนให้ทุกคนใช้เป็น

ขั้นตอน 1-3 ใช้เวลาเป็นวัน ขั้นตอน 4-6 ใช้เวลาเป็นสัปดาห์ ถึงเดือน

Cognitive load

ทุก tool ที่เพิ่ม = ทุกอย่างที่ทีมต้องเรียนรู้และ maintain

ก่อน: รู้แค่ Go + Postgres + Docker
หลัง: รู้ Go + Postgres + Docker + Prometheus + Grafana + Loki + Tempo + OTel + ...

ถ้าทีมมี 3 คน — เพิ่ม observability = เพิ่มภาระคนละ 20-30% — อาจไม่คุ้ม

Performance overhead

OTel SDK เพิ่ม latency ~1-5ms ต่อ request — และกิน memory ~10-50MB ขึ้นอยู่กับ sampling rate

Sampling 100% = เห็นทุก request แต่ performance hit สูง
Sampling 10% = เห็นแค่บางส่วน แต่แทบไม่มี overhead

Storage — ต้นทุนที่คนลืมคิด

traces กับ logs ใช้ storage มหาศาล — และ storage ไม่ได้ฟรี

ตัวอย่างจริง — 20 services, 1,000 req/s, 8 ชม/วัน:

Traces (sampling 100%, เก็บ 7 วัน):
  1,000 req/s × 3,600s × 8h = 28.8M requests/วัน
  เฉลี่ย 10 spans/request × ~2KB/span = ~576 GB/วัน
  เก็บ 7 วัน = ~4 TB

  ค่า storage (AWS S3): ~$90/เดือน
  ค่า storage (Grafana Cloud): ~$500/เดือน
  ค่า storage (Datadog): ~$2,000+/เดือน (คิดตาม ingestion + retention)

และนี่คือ sampling 100% — ทีมส่วนใหญ่ sampling แค่ 10-20% — แต่ก็ยังเป็นตัวเลขที่มีนัยสำคัญ

Traces โตเร็วกว่าที่คิด (self-hosted storage — S3-compatible @ ~$22.50/TB):

เดือนที่ 1: 20 services, เก็บ 7 วัน → 4 TB → $90
เดือนที่ 6: เพิ่ม 10 services, เก็บ 30 วัน → 30 TB → $675
เดือนที่ 12: trace ละเอียดขึ้น, เก็บ 90 วัน → 120 TB → $2,700

traces โตตาม services × retention × detail — ทั้งสามตัวมีแต่เพิ่ม ไม่เคยลด

วิธีคุม cost:

1. Sampling แบบหัว-ท้าย:
   - 100% เก็บเฉพาะ entry span (request เข้า)
   - 10% เก็บเต็มทุก span
   - error 100% เก็บหมด

2. Tail-based sampling:
   - ส่งทุก trace เข้า collector
   - collector ตัดสินใจเก็บเฉพาะ trace ที่ผิดปกติ (error, latency สูง)

3. ตั้ง retention policy:
   - traces: 3-7 วัน (พอ debug incident ล่าสุด)
   - metrics: 30-90 วัน (ดู trend)
   - logs: 7-14 วัน (debug)

💡 กฏง่าย ๆ: storage cost ของ traces มักจะมากกว่า CPU cost ของ services ที่คุณ monitor — ถ้า traces cost > infra cost — คุณทำอะไรผิดซักอย่าง

แล้วเมื่อไหร่ถึงคุ้ม

คุ้ม — เมื่อ

1. ใช้เวลาดีบั๊ก production เกิน 30 นาทีต่อครั้ง

ถามตัวเอง: incident ครั้งล่าสุด — ใช้เวลาเท่าไหร่กว่าจะรู้ว่าเกิดอะไรขึ้น?

ถ้าตอบว่า "ไม่รู้" หรือ "เกิน 30 นาที" — observability คุ้มแน่

2. มี service >10 ตัว หรือทีม >5 คน

เส้นแบ่งคร่าว ๆ: monolith → observability "nice to have" — 5+ services → "ควรมี" — 10+ services → "ต้องมี"

3. downtime มีผลต่อ revenue

ถ้าทุกนาทีที่ระบบล่ม = เสียเงิน — observability คือประกัน — จ่าย $2K/เดือน ดีกว่าเสีย $50K/นาทีตอนระบบล่ม

ไม่คุ้ม — เมื่อ

1. มี service <5 ตัว — และทีม <3 คน

เปิด log ทีละ service ก็ยังไหว — observability อาจ overkill

2. ยังไม่มี incident บ่อย

ถ้า production ยังนิ่ง — เงินก้อนนั้นไปเพิ่ม feature ดีกว่า

3. กำลัง validate product-market fit

startup ระยะแรก — metrics สำคัญกว่า observability — รู้ว่า revenue เท่าไหร่สำคัญกว่ารู้ว่า request ผ่านกี่ hop

เริ่มยังไง — แบบไม่เจ็บ

อย่าเริ่มด้วย "ลง observability platform" — เริ่มด้วยการถาม:

"incident ครั้งล่าสุด — อะไรคือคำถามที่เราใช้เวลาหาคำตอบนานที่สุด?"

ระดับ 1: Structured Logging (ฟรี ใช้เวลา 1 วัน)

// แทนที่จะ log แบบนี้
log.Printf("user %s login failed", userID)

// log แบบนี้
slog.Error("login failed",
    slog.String("user_id", userID),
    slog.String("reason", "invalid_password"),
    slog.String("trace_id", traceID),
)

trace_id คือกุญแจ — มันเชื่อม log ทุก service ที่ request นี้ผ่าน

💡 Level 1 ใช้ request-scoped ID (เช่น UUID จาก middleware) — ยังไม่ใช่ OTel trace ID จริง — Level 2 จะแทนที่ด้วย trace_id จาก span context ที่เชื่อมข้าม service ได้จริง

ระดับ 2: Tracing (ฟรี ค่อยเป็นค่อยไป)

เริ่มจากเพิ่ม span ในแต่ละ function:

import "go.opentelemetry.io/otel"

func GetUser(ctx context.Context, id string) (*User, error) {
    ctx, span := otel.Tracer("user-service").Start(ctx, "GetUser")
    defer span.End()
    // ... โค้ดเดิม
}

แต่นั่นทำให้เห็นแค่ span ภายใน process เดียว — ยังไม่เห็น flow ข้าม service

สิ่งที่ขาด — trace context propagation:

// HTTP client — inject traceparent header ให้เรียกข้าม service
import "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"

client := &http.Client{Transport: otelhttp.NewTransport(http.DefaultTransport)}
resp, _ := client.Get("http://payment-service/charge")  // trace_id ตามไปอัตโนมัติ

// HTTP server — extract traceparent จาก request ขาเข้า
handler := otelhttp.NewHandler(mux, "order-service")

ถ้า order-service ใช้ otelhttp.NewTransport ตอนเรียก payment-service — span ของทั้งสอง service จะถูก link เป็น trace เดียวกัน — นี่คือสิ่งที่ทำให้ "รู้ใน 2 นาที" จากบทนำเป็นจริง

การเพิ่ม span ใช้ ~3 บรรทัดต่อ function — otelhttp.NewTransport/NewHandler ใช้ 1 บรรทัด — ได้ tracing ทั้งระบบ โดยไม่ต้องเขียน propagation logic เอง

💡 หลักการเดียวกับ PII ใน log — ใช้กับ span attributes ด้วย: ห้ามใส่ email, user_id, order_id เป็น span tag — ใช้ trace_id + log correlation แทน

ระดับ 3: Dashboard + Alert (เริ่มมีค่าใช้จ่าย)

เริ่มจาก Grafana Cloud Free → ดู metrics + traces → ตั้ง alert เฉพาะ critical path

สรุป — คุ้มไหม

monolith → observability = nice to have
microservice → observability = requirement ไม่ใช่ feature

แต่ requirement ไม่ได้แปลว่าต้องทำเต็มรูปแบบ — เริ่มจาก structured logging + tracing (ฟรี, ใช้เวลาไม่นาน) — แล้วค่อยขยับไป dashboard + alert เมื่อเริ่มรู้สึกว่า "หา bug นานเกินไป"

และที่สำคัญ: อย่าตั้ง budget observability จากการ copy-paste plan ของทีม 300 คน — ทีม 5 คนต้องการ observability คนละแบบกับทีม 50 คน

📚 อ่านต่อ:

OpenTelemetry Go — tracing SDK

Grafana Cloud Free — เริ่มต้น observability ฟรี

Go 1.27 รับรอง QUERY — HTTP Method ใหม่ที่ GET ทำไม่ได้

Gophernment — Wed, 08 Jul 2026 12:21:11 +0000

Go 1.27 รับรอง QUERY — HTTP Method ใหม่ที่ GET ทำไม่ได้

⚠️ Go 1.27 ยังไม่ release — คาดเดือนสิงหาคม 2026 — QUERY method อยู่ในระหว่าง development (issue #80134)

ถ้าคุณเคยเขียน search API — คุณน่าจะเคยเจอปัญหานี้:

GET /api/search?q=golang&category=book&year=2025&author=donovan

พารามิเตอร์เยอะมากจน URL ยาวเป็นหางว่าว — แล้วยิ่งถ้าต้องส่ง query ที่ซับซ้อน (nested conditions, OR, range queries) — GET แทบจะใช้งานไม่ได้

แล้วก็มีคนเสนอว่า: "งั้นใช้ POST สิ" — แต่ POST ไม่ใช่ safe method — มันไม่ควร cache, search engine ไม่ index, CDN ไม่ cache

ทางออกที่วงการ HTTP ออกแบบมาตั้งแต่ปี 2022: QUERY method

และตอนนี้ Go 1.27 กำลังจะรับรองมันอย่างเป็นทางการ

QUERY คืออะไร

QUERY คือ HTTP method ที่ถูกกำหนดใน RFC 9110 (HTTP Semantics, มิถุนายน 2022)

QUERY /api/search HTTP/1.1
Content-Type: application/json

{
  "q": "golang",
  "category": "book",
  "year": 2025,
  "filters": {
    "price": {"gte": 20, "lte": 50},
    "language": ["en", "th"]
  }
}

คุณสมบัติ	GET	POST	QUERY
Safe (ไม่เปลี่ยน state)	✅	❌	✅
Idempotent (เรียกซ้ำได้ผลลัพธ์เดิม)	✅	❌	✅
มี request body ได้	❌ (ทำได้แต่ไม่ควร)	✅	✅
Cache ได้	✅	❌	✅
Search engine index	✅	❌	✅

QUERY = GET + request body — ปลอดภัย, cache ได้, ส่ง query ซับซ้อนได้

ทำไมถึงต้องมี QUERY — ปัญหาที่ GET แก้ไม่ได้

ปัญหาที่ 1: URL ยาวเกิน

GET /api/search?q=golang&tags=programming,language,backend&...
→ URL 500+ ตัวอักษร — หลาย browser/proxy มี limit ที่ 2,048

QUERY ส่ง body แทน:

QUERY /api/search
Content-Type: application/json
{"q": "golang", "tags": ["programming", "language", "backend"], ...}

ปัญหาที่ 2: ข้อมูล sensitive ใน URL

GET /api/search?email=user@example.com&ssn=1234
→ URL ถูก log โดย proxy, server, CDN — SSN รั่ว!

QUERY: ข้อมูลอยู่ใน body — ไม่ปรากฏใน log

ปัญหาที่ 3: Query ซับซ้อนเกิน query string

# Elasticsearch-style query — เขียนใน query string ไม่ได้
{
  "bool": {
    "must": [
      {"term": {"status": "active"}},
      {"range": {"created_at": {"gte": "2025-01-01"}}}
    ],
    "should": [
      {"match": {"title": "golang"}},
      {"match": {"description": "go programming"}}
    ]
  }
}

การมี QUERY เปลี่ยนอะไร

ก่อน QUERY — ทางเลือกที่มี

1. GET + query string → URL ยาว, sensitive data รั่ว
2. POST + body → ใช้ได้ แต่ผิด semantics → ไม่ cache, SEO ไม่ดี
3. POST + body + X-HTTP-Method-Override → workaround แต่ไม่ standard

หลัง QUERY — ทางเลือกใหม่

QUERY /api/search → body = query → safe, cacheable, clean

Go 1.27 — วิธีใช้

package main

import (
    "fmt"
    "net/http"
)

func searchHandler(w http.ResponseWriter, r *http.Request) {
    // Go 1.27 — ใช้ MethodQuery แทน string "QUERY"
    if r.Method != http.MethodQuery {
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
        return
    }

    // อ่าน request body — เหมือน POST
    var query SearchQuery
    json.NewDecoder(r.Body).Decode(&query)

    results := search(query)
    json.NewEncoder(w).Encode(results)
}

func main() {
    http.HandleFunc("QUERY /api/search", searchHandler)
    http.ListenAndServe(":8080", nil)
}

ก่อน Go 1.27: ต้องใช้ string "QUERY" ตรง ๆ — http.MethodQuery ยังไม่มี

Go 1.27: เพิ่ม http.MethodQuery — constant มาตรฐาน เหมือน http.MethodGet, http.MethodPost

คนทำงานควรปรับตัวอย่างไร

ถ้าคุณเป็น Backend Developer

1. ใช้ QUERY สำหรับ search endpoint

- r.HandleFunc("POST /api/search", searchHandler)
+ r.HandleFunc("QUERY /api/search", searchHandler)

ประโยชน์:

✅ CDN cache ได้ — ลด load server
✅ Semantics ถูกต้อง — POST ไม่ใช่วิธีที่ถูกสำหรับการ search
✅ API ของคุณ self-documenting — QUERY บอกว่า "นี่คือการอ่านข้อมูล"

2. อัปเดต API documentation

Old: POST /api/search (ใช้ POST เพราะ query ซับซ้อนเกิน GET)
New: QUERY /api/search (ใช้ QUERY — safe, cacheable)

3. รองรับทั้งสองวิธีในช่วงเปลี่ยนผ่าน

func searchHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodQuery && r.Method != http.MethodPost {
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
        return
    }
    // ... logic
}

ถ้าคุณเป็น Frontend Developer

// จาก POST
const res = await fetch("/api/search", {
    method: "POST",
    body: JSON.stringify(query)
});

// เป็น QUERY
const res = await fetch("/api/search", {
    method: "QUERY",
    body: JSON.stringify(query)
});

ถ้าคุณเป็น DevOps / Infrastructure

CDN: อัปเดต config ให้ cache QUERY requests
Proxy/Load Balancer: เช็คว่ารองรับ QUERY method หรือไม่ (บางตัวอาจ reject)
Logging/Monitoring: เพิ่ม QUERY ใน metrics
WAF/Firewall: allow QUERY method

สถานะปัจจุบัน

RFC 9110:        ✅ Published (June 2022)
Browser support: ⚠️ fetch() รองรับ แต่ยังไม่ widespread
Go support:      🚧 Go 1.27 (August 2026) — ในระหว่างพัฒนา
GitHub Issue:    #80134 (darkweak, opened June 2026)

สรุป

QUERY คือ GET ที่มี body — safe, idempotent, cacheable — ออกแบบมาสำหรับ search และ query ที่ซับซ้อน

Go 1.27 เป็น milestone สำคัญที่ทำให้ QUERY กลายเป็น first-class citizen ใน ecosystem — หลังจากนี้ เราน่าจะเห็น API เปลี่ยนจาก POST /search เป็น QUERY /search มากขึ้น

📚 อ่านต่อ:

RFC 9110: HTTP Semantics — QUERY method definition

Go Issue #80134 — net/http: add QUERY HTTP method

Go Issue #80058 — proposal: MethodQuery constant

Go 1.27 Release Notes — draft

📅 เขียนเมื่อ: กรกฎาคม 2026 | Go 1.27 อยู่ในระหว่างพัฒนา

Go errors .Is กับ .As เป็นเพื่อนกัน

Gophernment — Wed, 08 Jul 2026 04:31:44 +0000

Go errors .Is กับ .As เป็นเพื่อนกัน

เวลาเริ่มเขียน Go — เรามักเช็ค error ด้วย == ตรง ๆ:

if err == sql.ErrNoRows {
    // handle
}

แต่พอเริ่มใช้ fmt.Errorf("...: %w", err) wrap error — == ใช้ไม่ได้แล้ว

err := getUser()
// err = "GetUser: sql: no rows in result set"
// err == sql.ErrNoRows → false! เพราะมันถูก wrap แล้ว

Go เลยมี 2 ฟังก์ชันให้: errors.Is และ errors.As — หน้าตาคล้ายกัน แต่หน้าที่ต่างกัน

`fmt.Errorf` กับ `%w` — จุดเริ่มต้นของทุกอย่าง

ก่อนจะเข้าใจ Is กับ As — ต้องเข้าใจ %w ก่อน

import "fmt"

func getUser(id string) (*User, error) {
    user, err := db.QueryRow(...)
    if err != nil {
        return nil, fmt.Errorf("getUser(%s): %w", id, err)
        //                          ↑↑↑↑↑↑↑↑↑↑↑
        //                          wrap err ด้วย %w
    }
    return user, nil
}

%w คือ verb พิเศษที่ "ห่อ" error ไว้ข้างใน — ไม่ใช่แค่ต่อ string แบบ %v

original := sql.ErrNoRows
wrapped := fmt.Errorf("getUser: %w", original)

fmt.Println(wrapped.Error())
// "getUser: sql: no rows in result set"

// หน้าตาภายใน:
// wrapped = &wrapError{
//     msg: "getUser",
//     err: sql.ErrNoRows  ← เก็บ original ไว้!
// }

%w ทำให้เกิด error chain — error ลูกถูกซ้อนอยู่ใน error แม่ — และ Is กับ As รู้วิธีเดิน chain นี้

`errors.Is` — "ใช่ error นี้หรือเปล่า?"

import "errors"

err := getUser("42")
// err = "getUser(42): sql: no rows in result set"

if errors.Is(err, sql.ErrNoRows) {
    // ✅ true — Is เดินตาม chain แล้วเจอ sql.ErrNoRows ข้างใน
    fmt.Println("not found")
}

errors.Is ถามว่า: "error นี้ (หรือ error ที่ถูก wrap ไว้ข้างใน) คือ sql.ErrNoRows หรือไม่?"

หลักการทำงาน:

1. เปรียบเทียบ err == sql.ErrNoRows? → false (คนละ type)
2. err มี Unwrap() ไหม? → มี (เพราะใช้ %w)
3. unwrap → "sql: no rows..."
4. เปรียบเทียบ unwrapped == sql.ErrNoRows? → ✅ true!
5. ตอบ true

ตัวอย่างเพิ่มเติม:

// เช็คหลายระดับ
err := fmt.Errorf("handler: %w",
          fmt.Errorf("service: %w",
              sql.ErrNoRows))

errors.Is(err, sql.ErrNoRows) // ✅ true — ลงลึก 2 ชั้น

`errors.As` — "เป็น error type นี้หรือเปล่า?"

var pathErr *os.PathError

err := os.Open("/nonexistent/file")

if errors.As(err, &pathErr) {
    // ✅ true — err เป็น *os.PathError (หรือมี *os.PathError อยู่ใน chain)
    fmt.Println("path:", pathErr.Path)      // "/nonexistent/file"
    fmt.Println("op:", pathErr.Op)          // "open"
}

errors.As ถามว่า: "error นี้ (หรือ error ที่ถูก wrap ไว้ข้างใน) เป็น type *os.PathError หรือไม่? — ถ้าใช่ ใส่ค่าให้ตัวแปรที่ส่งเข้าไป"

หลักการทำงาน:

1. err เป็น *os.PathError? → ใช่!
2. ใส่ค่า err เข้าไปใน pathErr (ผ่าน pointer ที่ส่งเข้า)
3. ตอบ true

ข้อแตกต่างสำคัญ: As รับ pointer to error type — ไม่ใช่ error value — เพราะมันต้อง assign ค่ากลับมา

// ❌ ผิด — As ต้องการ pointer
if errors.As(err, os.PathError{}) { ... }

// ✅ ถูก — pointer to error type
var target *os.PathError
if errors.As(err, &target) { ... }

// ✅ ถูก — ใช้ interface ก็ได้
var netErr net.Error
if errors.As(err, &netErr) { ... }

`Is` vs `As` — ต่างกันตรงไหน?

	`errors.Is`	`errors.As`
คำถาม	"ใช่ error นี้หรือเปล่า?"	"เป็น type นี้หรือเปล่า?"
เทียบกับ	value (sentinel error)	type (error struct)
รับ parameter	error value โดยตรง	pointer to error type
ได้อะไรกลับ	`true/false`	`true/false` + ใส่ค่าให้ตัวแปร
ใช้เมื่อ	อยากรู้ว่าใช่ error ที่รู้จักไหม	อยากรู้ว่าเป็น type อะไร และเข้าถึง field
ตัวอย่าง	`errors.Is(err, sql.ErrNoRows)`	`errors.As(err, &pathErr)`

วิธีจำ — "Is เช็คชื่อ, As เช็ค type"

Is → "Is this THAT error?" → เปรียบเทียบ value
As → "As WHAT type?" → ตรวจสอบ type + extract

ตัวอย่างที่ใช้ทั้งคู่

func handleError(err error) {
    // 1. เช็คก่อนว่า "ใช่ not found ไหม?"
    if errors.Is(err, sql.ErrNoRows) {
        fmt.Println("not found")
        return
    }

    // 2. เช็คต่อว่า "เป็น path error ไหม?" — ถ้าใช่ ดูว่าไฟล์ไหน
    var pathErr *os.PathError
    if errors.As(err, &pathErr) {
        fmt.Printf("can't open %s\n", pathErr.Path)
        return
    }

    // 3. เช็ค transient network error
    var netErr net.Error
    if errors.As(err, &netErr) && netErr.Temporary() {
        fmt.Println("temporary — retry")
        return
    }

    fmt.Printf("unexpected: %v\n", err)
}

Custom Error Types — ใช้กับ `Is` และ `As`

// 1. Sentinel error — ใช้กับ Is
var ErrPermission = errors.New("permission denied")

// 2. Custom error type — ใช้กับ As
type ValidationError struct {
    Field string
    Value any
}

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

// ใช้ Is กับ sentinel
if errors.Is(err, ErrPermission) {
    fmt.Println("no permission")
}

// ใช้ As กับ custom type
var valErr *ValidationError
if errors.As(err, &valErr) {
    fmt.Printf("field %s is invalid\n", valErr.Field)
}

🧠 Hint สำหรับจำ

Is  →  "Is this error the SAME as...?"
        → เปรียบเทียบค่า เหมือน == แต่เดิน chain ให้

As  →  "As WHAT TYPE?"
        → ตรวจ type + extract value เหมือน type assertion แต่เดิน chain ให้

สองคำ: Is = identity, As = extraction

📊 สรุป

ฟังก์ชัน	ใช้กับ	ใช้เมื่อ
`fmt.Errorf("...: %w", err)`	—	สร้าง error chain
`errors.Is(err, target)`	Sentinel errors (`var ErrX = errors.New(...)`)	เช็คว่าใช่ error นี้ไหม
`errors.As(err, &target)`	Error types (`*PathError`, `net.Error`)	เช็คว่าเป็น type นี้ไหม + ดึงค่า

📚 อ่านต่อ:

Go Blog: Working with Errors

errors package docs

fmt package — %w verb

ภาษาโปรแกรมมิ่งที่ syntax ง่าย AI ช่วยเราได้ดีกว่า จริงหรือ?

Gophernment — Tue, 07 Jul 2026 01:25:59 +0000

ภาษาโปรแกรมมิ่งที่ syntax ง่าย AI ช่วยเราได้ดีกว่า จริงหรือ?

"เขียน Go แล้ว Copilot แม่นกว่าเขียน Java" — เคยได้ยินไหม?
หรือ "Python มันง่าย AI เลยเก่ง" — จริงหรือแค่ confirmation bias?

นิยาม "ดีกว่า" ในบทความนี้: token ประหยัดกว่า, over-generation (babbling) น้อยกว่า, pass rate สูงกว่า — ไม่ใช่ hallucination (invented API, เรียก library ที่ไม่มีจริง) — งานวิจัยเรื่อง hallucination ข้ามภาษายังไม่มี

บทความนี้พาไปดู 3 งานวิจัย ที่ตอบคำถามนี้ด้วยข้อมูล

📄 งานวิจัยที่ 1: Token Sugar — "ยิ่ง verbose ยิ่งเปลือง token"

Token Sugar: Making Source Code Sweeter for LLMs through Token-Efficient Shorthand (ASE 2025)

หมายเหตุ: งานวิจัยนี้วัดประสิทธิภาพการลด token ภายใน corpus — ไม่ใช่การเปรียบเทียบข้ามภาษา — ตัวอย่าง Java vs Go ด้านล่างเป็นการตีความของผู้เขียนเพื่อให้เห็นภาพ
โดย Zhensu Sun, Chengran Yang และคณะ — https://arxiv.org/abs/2512.08266

ข้อค้นพบ:

"The inherent verbosity of programming languages, such as unnecessary formatting elements and lengthy boilerplate code, leads to inflated token counts"

ภาษาโปรแกรมมิ่งที่ verbose — มี boilerplate เยอะ, มี formatting elements มาก — ทำให้ token count สูงขึ้นโดยไม่จำเป็น

ตัวเลข: Token Sugar สามารถลด token ได้ 15.1% ใน source code และ 11.2% ระหว่าง generation — โดย คงค่า Pass@1 เท่าเดิม — แปลว่าที่ลดไปไม่ใช่เนื้อหาสำคัญ แต่มันคือ "ขยะ" ทาง syntax ที่ LLM ต้อง generate โดยเปล่าประโยชน์

นัยสำคัญ:

Java: public static void main(String[] args) { System.out.println("hello"); }
Go:   func main() { fmt.Println("hello") }

Java: ~20+ tokens
Go:   ~8 tokens
→ ฟังก์ชันเดียวกัน — Go ใช้ token น้อยกว่าครึ่ง

ทุก token ที่ประหยัดได้ = เงินที่ประหยัดได้ = context window ที่เหลือไว้ให้ logic จริง

📄 งานวิจัยที่ 2: Babbling Suppression — "Java พล่ามมากกว่า Python"

Babbling Suppression: Making LLMs Greener One Token at a Time (2026)
โดย Lola Solovyeva, Fernando Castor — https://arxiv.org/abs/2604.06755

ข้อค้นพบ:

"Babbling occurs across all tested models, with higher frequency in Java than in Python"

"Babbling" (การพูดพล่าม) คือการที่ LLM สร้าง output ที่มากเกินจำเป็น — เช่น generate getter/setter ทั้งคลาสทั้งที่ขอแค่ method เดียว, ใส่ import ที่ไม่ได้ใช้, comment ยาวเกินเหตุ

งานวิจัยนี้พบว่า Java เกิด babbling มากกว่า Python อย่างมีนัยสำคัญ — และลด energy consumption ได้มากถึง 65% สำหรับ Python, 62% สำหรับ Java โดยการ suppress babbling

ทำไม Java ถึงพล่ามมากกว่า?

Python:  def add(a, b): return a + b           ← 2 บรรทัด
Java:    public int add(int a, int b) {         ← ต้องมี type, access modifier,
             return a + b;                           return statement, bracket
         }

Java บังคับให้ LLM ต้อง "พูด" เยอะกว่าเพื่อแสดงความตั้งใจเดียวกัน — ยิ่งต้องพูดเยอะ = ยิ่งมีโอกาสพูดผิด

📄 งานวิจัยที่ 3: MultiPL-E — "ภาษาไหน LLM เก่งสุด?"

MultiPL-E: A Scalable and Extensible Approach to Benchmarking Neural Code Generation (2022)
โดย Federico Cassano และคณะ — https://arxiv.org/abs/2208.08227

ข้อค้นพบ:

สร้าง benchmark ที่ทดสอบ LLM ข้าม 18+ ภาษา พร้อมกัน
พบว่า "language frequency" (ปริมาณ training data ของภาษานั้น) เป็นปัจจัยอันดับ 1
ภาษาใกล้เคียง Python มักทำคะแนนได้ดี (เพราะ Python มี training data มหาศาล)
ภาษาที่ training data น้อย → คะแนนต่ำ แม้ syntax จะเรียบง่าย

สรุปจาก MultiPL-E: Syntax ง่าย ≠ AI เก่งเสมอไป — ถ้าภาษานั้นไม่มี training data — AI ก็ทำไม่ได้

⚠️ Recency caveat: MultiPL-E (2022) ใช้ Codex/CodeGen/InCoder — โมเดล pre-2024 — ปัจจุบัน coding agent ใช้ test-execution feedback loop และ RAG ซึ่งอาจลดผลของตัวภาษาลงจากที่ paper วัดไว้ — ข้อสรุปจากงานนี้จึงอาจ conservative เมื่อเทียบกับความสามารถของโมเดลปัจจุบัน

📊 สรุป — 3 ปัจจัยที่ตัดสินว่า AI จะเก่งกับภาษาไหน

อันดับ	ปัจจัย	หลักฐาน	น้ำหนัก
🥇	Training Data — ภาษานั้นมีโค้ดบน GitHub เยอะแค่ไหน	MultiPL-E (cross-language, 18+ languages)	✅ หนักแน่น
🥈	Verbosity — ภาษานั้น verbose แค่ไหน (กระทบ token cost)	Token Sugar (ไม่ใช่ cross-language)	⚠️ circumstantial
🥉	Syntax Complexity — ซับซ้อน → babbling มากขึ้น	Babbling Suppression (2 ภาษาเท่านั้น)	⚠️ circumstantial

หมายเหตุ: MultiPL-E เป็นงานเดียวที่ทดสอบข้ามภาษาโดยตรง — อีก 2 paper เป็นหลักฐานแวดล้อม (ไม่ cross-language / ทดสอบแค่ 2 ภาษา) — generalization ไปยังภาษาอื่นเป็นการ extrapolate ของผู้เขียน

ภาพรวม — จัดกลุ่มภาษา

นี่คือการตีความของผู้เขียน — ไม่ใช่ finding จากงานวิจัยโดยตรง:

กลุ่ม	ภาษา	AI เก่ง?	Token cost	Babbling
🟢 Sweet Spot	Python, JavaScript, TypeScript, Go	✅ เก่ง	ต่ำ	น้อย
🟡 พอใช้ได้	Ruby, Rust, Kotlin, Swift	⚠️ ปานกลาง	กลาง	กลาง
🔴 ท้าทาย	Java, C++, C#, PHP	⚠️ เก่งในเรื่องทั่วไป แต่ verbose	สูง	มาก

💡 Go อยู่ในกลุ่ม Sweet Spot — syntax เรียบง่ายเหมือน Python — token cost ต่ำ — babbling น้อย — ทำให้ LLM ทำงานกับ Go ได้ดีเทียบเคียง Python

🎯 คำตอบสุดท้าย

"ภาษา syntax ง่ายทำให้ AI หลอนน้อยลง จริงไหม?"

✅ จริง — แต่แค่ส่วนนึงของสมการ

ปัจจัยอันดับ 1 คือ training data
ปัจจัยอันดับ 2 คือ verbosity (กระทบ token cost)
ปัจจัยอันดับ 3 คือ syntax complexity (กระทบ babbling)

ภาษาที่ "ใช่" สำหรับ AI-assisted coding คือภาษาที่:

มี training data มาก → AI แม่น
syntax กระชับ → ประหยัด token
ไม่บังคับ boilerplate → AI ไม่ต้องพล่าม

Python ชนะขาดเรื่อง training data — Go ชนะเรื่องความกระชับ — JavaScript/TypeScript สมดุลทั้งสองด้าน — Java/C++ เก่งในเชิงความสามารถ แต่แพ้เรื่อง token cost

📚 Sources:

Token Sugar (ASE 2025) — verbosity → token inefficiency

Babbling Suppression (2026) — Java babbles more than Python

MultiPL-E (2022) — cross-language LLM benchmark

GitHub Copilot: Token Efficiency — June 2026

Null, nil, None — คำว่า 'ไม่มีค่า' ในแต่ละภาษา

Gophernment — Mon, 06 Jul 2026 07:20:00 +0000

Null, nil, None — คำว่า "ไม่มีค่า" ในแต่ละภาษา

เวลาเราเขียนโปรแกรม — วันนึงเราจะต้องเจอ "การไม่มีค่า"

บางภาษามันคือ null บางภาษามันคือ nil บางภาษามันคือ None — แต่มันคือสิ่งเดียวกันใช่ไหม?

ไม่ใช่ — และความต่างเล็ก ๆ นี่แหละที่ทำให้โปรแกรมพังได้

ภาพรวม — แต่ละภาษาเรียกชื่ออะไร

ภาษา	ชื่อเรียก	ตัวอย่าง
Java	`null`	`String s = null;`
JavaScript	`null` + `undefined`	`let x = null; let y;`
Python	`None`	`x = None`
Ruby	`nil`	`x = nil`
C/C++	`NULL` / `nullptr`	`int* p = NULL;`
Go	`nil` + zero values	`var s *string = nil`

เห็นว่า Ruby กับ Go ใช้ nil เหมือนกัน — แต่เบื้องหลังต่างกันโดยสิ้นเชิง

Java — `null` คือตัวปัญหา

String name = null;
System.out.println(name.length());  // 💥 NullPointerException!

ใน Java — null คือ "การไม่มี object" — และทุกครั้งที่คุณเรียก method บน null — โปรแกรมพัง

Java แก้ด้วยการเช็ค if (x != null) ทุกที่ — หรือใช้ Optional (Java 8+) — แต่ null ก็ยังแฝงตัวอยู่ทุกมุม

// Java Optional — พยายามกำจัด null
Optional<String> name = Optional.ofNullable(getName());
name.ifPresent(System.out::println);

JavaScript — มีสองแบบ ซวยสองเท่า

let x = null;        // "ฉันจงใจให้มันว่าง"
let y;               // undefined — "ฉันลืมใส่ค่า"

console.log(x);      // null
console.log(y);      // undefined
console.log(typeof null);  // "object" ← bug ในภาษา!

null == undefined;    // true  ← อ้าว?
null === undefined;   // false ← อ้าววว?

JavaScript มีทั้ง null และ undefined — และการที่ typeof null === "object" เป็น bug ที่ฝังมาตั้งแต่ปี 1995 — แก้ไม่ได้แล้วเพราะคนใช้กันทั้งโลก

Python — `None` คือ singleton

x = None
y = None
print(x is y)  # True — None มีตัวเดียวในจักรวาล

ใน Python — None เป็น singleton — มีแค่ instance เดียวในหน่วยความจำ — is ใช้เช็คได้

def get_user(id):
    return None  # "ไม่เจอ"

user = get_user(42)
if user is None:
    print("ไม่พบผู้ใช้")

สะอาด ตรงไปตรงมา — ไม่มี NullPointerException — แต่ก็ไม่ได้ช่วยให้ปลอดภัยขึ้น — ถ้าลืมเช็ค None — โปรแกรมก็พังตอนใช้ user.name อยู่ดี

Go — `nil` คืออะไร? และทำไมมันถึงหลอกเรา

Go ใช้ nil — แต่ความหมายของมันเปลี่ยนไปตาม type

var p *int = nil        // nil pointer
var s []int = nil       // nil slice — แต่ใช้ append ได้!
var m map[string]int = nil  // nil map — อ่านได้ แต่เขียนไม่ได้!
var ch chan int = nil   // nil channel — block ตลอดกาล
var fn func() = nil     // nil function — เรียกแล้ว panic

nil slice: ต่างจากภาษาอื่น — คุณใช้ append บน nil slice ได้!

var names []string       // nil slice — len=0
names = append(names, "Alice")  // ✅ ได้เลย! ไม่ต้อง make ก่อน
fmt.Println(names)       // [Alice]

nil map: อ่านได้ แต่เขียนไม่ได้:

var m map[string]int     // nil map
_ = m["key"]             // ✅ ได้ 0 (zero value)
m["key"] = 1             // 💥 panic: assignment to entry in nil map

หลุมพรางใน Go — `nil` interface ≠ `nil` pointer

นี่คือ bug ที่คนเขียน Go เจอแล้วเจออีก:

func getUser() *User {
    return nil  // ไม่มี user
}

func getUserAsInterface() error {
    return getUser()  // return nil pointer
}

func main() {
    err := getUserAsInterface()
    if err != nil {
        fmt.Println("มี error!")  // ❌ มันเข้าเงื่อนไขนี้ทั้งที่ควรเป็น nil!
    }
}

ทำไม? interface ใน Go ไม่ใช่แค่ "ค่า" — มันคือ (type, value) — tuple:

var p *User = nil
fmt.Println(p == nil)  // true — pointer nil

var err error = p      // เก็บ (*User, nil) — type ไม่ใช่ nil!
fmt.Println(err == nil) // false!?

interface err มี type = *User (ไม่ใช่ nil) — แต่ value = nil — interface โดยรวมจึง ไม่ใช่ nil

วิธีแก้: return nil แบบไม่มี type — ไม่ใช่แค่ pointer nil:

func getUserAsInterface() error {
    u := getUser()
    if u == nil {
        return nil  // ✅ nil แบบไม่มี type — interface nil จริง
    }
    return u
}

Zero Values — Go ไม่มี "ไม่มีค่า"

แนวคิดที่ต่างจากภาษาอื่นมาก: Go ไม่มี uninitialized variable

var i int        // 0
var s string     // "" (empty string — ไม่ใช่ nil!)
var b bool       // false
var p *int       // nil (แต่ type ชัดเจนว่าเป็น *int)

ใน Java/Python/JS — ตัวแปรที่ยังไม่ assign ค่าอาจเป็น null/None/undefined

ใน Go — ทุกอย่างมี zero value — ค่าเริ่มต้นของ type นั้น — คุณไม่ต้องกลัวว่าจะลืม initialize

type User struct {
    Name string  // "" (ไม่ใช่ nil)
    Age  int     // 0
}

var u User
fmt.Println(u.Name)  // "" — ไม่พัง!

เปรียบเทียบกับ Java:

class User {
    String name;  // null!
    int age;      // 0
}

User u = new User();
u.name.length();  // 💥 NullPointerException!

เทียบกัน — ภาษาไหนชนะ

	null error	zero value	nil slice ใช้ได้	interface nil trap
Go	❌ (แต่มี interface trap)	✅	✅	⚠️ หลุมพราง
Java	💥 NullPointerException	❌ (Object = null)	—	—
JavaScript	💥 undefined + null	—	—	—
Python	💥 AttributeError	❌	—	—
Ruby	💥 NoMethodError	❌	—	—

สรุป

ภาษา	ชื่อ	จุดอ่อน
Java	`null`	NullPointerException ทุกที่ — `Optional` ช่วยได้นิดหน่อย
JavaScript	`null`, `undefined`	สองแบบ — `typeof null === "object"`
Python	`None`	สะอาดสุด — แต่ต้องเช็ค `is None` เอง
Go	`nil` + zero values	ปลอดภัยกว่า — แต่ interface nil trap หลอกได้

หัวใจของ Go: ตัวแปรทุกตัวมีค่าเสมอ — แม้จะเป็น "ค่าเริ่มต้น" — คุณจะไม่เจอ NullPointerException ใน Go — แต่คุณจะเจอ "interface nil trap" แทน

และนั่นคือบทเรียนที่คนเขียน Go ทุกคนต้องผ่าน — nil กับ nil มันไม่เหมือนกัน

📚 อ่านต่อ:

Go FAQ: Why is my nil error value not equal to nil?

Understanding nil in Go

ทำไม Go ถึง compile ไว — เล่าจากห้องเซิร์ฟเวอร์ Google ที่ร้อนระอุ

Gophernment — Mon, 06 Jul 2026 06:27:28 +0000

ทำไม Go ถึง compile ไว — เล่าจากห้องเซิร์ฟเวอร์ Google ที่ร้อนระอุ

ปี 2007 — ห้องเซิร์ฟเวอร์ของ Google ร้อนจนแทบละลาย

ไม่ใช่เพราะอากาศ — แต่เพราะ คอมไพเลอร์ C++

นักพัฒนาที่ Google สามคน — Robert Griesemer, Rob Pike, และ Ken Thompson — กำลังรอโค้ด compile

Ken Thompson คือใคร? เขาคือคนที่สร้าง Unix, สร้าง ภาษา B (บรรพบุรุษของ C), ร่วมคิดค้น UTF-8, และได้รับ Turing Award — รางวัลโนเบลของวงการคอมพิวเตอร์

สามคนนี้... นั่งรอโค้ด compile เป็นสิบนาที

Pike เล่าในภายหลังว่า: "เราเบื่อที่จะรอ — ก็เลยสร้างภาษาใหม่"

เรื่องเล่าก่อน Go — ทำไม C++ ที่ Google ถึง compile ช้า

ลองนึกภาพ: Google มีโค้ด C++ มหาศาล — หนึ่งไฟล์ #include อีกไฟล์ — #include ซ้อน #include — กลายเป็น chain ยาวเป็นกิโลเมตร

// main.cc
#include "server.h"
// server.h
#include "handler.h"
// handler.h
#include "request.h"
// request.h
#include "database.h"
// database.h — #include อีก 20 ไฟล์...

เปลี่ยนโค้ด 1 บรรทัดใน database.h → ทุกไฟล์ที่ #include chain มาถึงต้อง compile ใหม่หมด → เป็นชั่วโมง

และอย่าลืม — C++ มี template, มี preprocessor, มี header files, มี forward declaration, มี ODR (One Definition Rule) — ทุกอย่างทำให้ compiler ต้องทำงานหนักขึ้น

สามคนนี้ตัดสินใจว่า: "ภาษาใหม่ต้อง compile ไว — มาก"

ข้อที่ 1: ไม่มี Header Files — อ่านตรง ๆ

Go ไม่มี .h ไฟล์ — compiler อ่าน .go โดยตรง:

// Go — import อย่างเดียว ไม่มี include
import (
    "net/http"
    "encoding/json"
)

compiler รู้ว่า package net/http export อะไรบ้าง — อ่านครั้งเดียว — จบ

C++ ต้องทำอะไร? compiler อ่าน header.h → preprocessor ไล่ #include → ต่อ chain → อ่านซ้ำ 20 รอบ — source file เดียวอาจใหญ่เป็นแสนบรรทัดก่อนถึง compiler จริง

Go: 1 ไฟล์ = 1 ไฟล์ — compiler รู้ทันทีว่าต้องอ่านอะไร

ข้อที่ 2: Dependency Graph — ห้ามวกกลับมาที่เดิม

Go ออกแบบ dependency เป็น DAG (Directed Acyclic Graph) — ห้าม circular import

// ✅ ถูก — dependency เป็น tree
package A → import B
package B → import C

// ❌ ผิด — circular — compile ไม่ผ่าน
package A → import B
package B → import A  // compile error!

ทำไมถึงเร็ว? ถ้า dependency เป็น DAG — compiler สามารถ:

เรียงลำดับการ compile ได้ — compile C ก่อน, แล้ว B, แล้ว A
ทำ parallel ได้ — compile C, B, A พร้อมกันถ้าไม่ขึ้นต่อกัน
รู้ว่าไฟล์ไหนต้อง compile ใหม่ — เปลี่ยน C อย่างเดียว → A, B ไม่ต้อง compile ใหม่ถ้า interface ไม่เปลี่ยน

Go ใช้ DAG ตั้งแต่ดีไซน์ — ไม่ใช่ afterthought

ข้อที่ 3: Import ที่ไม่ได้ใช้ = Error

import "fmt"
import "os"  // ❌ compile error: imported and not used

func main() {
    fmt.Println("hello")
}

ฟังดูน่ารำคาญ — แต่มันมีเหตุผล: compiler ไม่ต้องเสียเวลาอ่าน package ที่คุณ import มาแต่เปล่าประโยชน์

ใน C++ — คุณ #include <vector> แล้วไม่ได้ใช้ — compiler ยังต้องอ่านทั้งไฟล์ — สิ้นเปลือง

Go: goimports จัดการให้ — import เอง, ลบเอง — คุณไม่ต้องคิด

ข้อที่ 4: Object Files อัจฉริยะ — metadata อยู่ส่วนหัว

เวลา Go compile package — มันสร้าง .a (object file) ที่ สมบูรณ์ในตัวเอง — และสิ่งที่สำคัญคือการจัดเรียงข้อมูล

math.a:
  ┌─────────────────────────────┐
  │ METADATA (ส่วนหัว)            │
  │  - รายชื่อ symbols ที่ export   │
  │  - รายชื่อ dependencies       │
  │  - type information (สำหรับ  │
  │    reflection)              │
  ├─────────────────────────────┤
  │ MACHINE CODE (ส่วนท้าย)       │
  │  - โค้ดจริงของ package math   │
  └─────────────────────────────┘

ประเด็นสำคัญ: Metadata อยู่ที่ ส่วนหัวของไฟล์ — เวลา package B import math — compiler อ่านแค่ metadata (ไม่กี่ KB) — ไม่ต้อง parse source code ทั้งหมด (หลายพันบรรทัด) — ไม่ต้อง re-type-check

เปรียบเทียบกับ C++:

// C++ — ทุกครั้งที่ compile main.cc
#include "math.h"   // ← ต้องเปิด math.h → parse → type-check → expand
                    //    math.h อาจ include math_impl.h → parse → expand
                    //    math_impl.h อาจ include vector → parse → expand
                    //    ทั้งหมดนี้เกิดขึ้นซ้ำในทุก .cc ที่ใช้ math.h

Go: อ่าน metadata ครั้งเดียวต่อ package — C++: parse headers ซ้ำในทุก translation unit

💡 ลองนึกภาพมี 100 ไฟล์ import net/http — C++ parse header ซ้ำ 100 รอบ — Go อ่าน metadata ของ net/http.a 100 รอบ แต่การอ่าน metadata (ไม่กี่ KB) เร็วกว่า parse source (หลายพันบรรทัด) หลายเท่า

ข้อที่ 5: Plan 9 Assembly — "ภาษาเดียว ทุก CPU"

Go ใช้ Plan 9 assembly — assembly language ที่ออกแบบโดยทีมเดียวกับ Unix — Ken Thompson เป็นหนึ่งในนั้น

// Plan 9 assembly ของ Go
TEXT ·Add(SB), NOSPLIT, $0-16
    MOVQ    a+0(FP), AX
    ADDQ    b+8(FP), AX
    MOVQ    AX, ret+16(FP)
    RET

แล้วมันต่างจากภาษาอื่นยังไง?

C/C++: compiler ใช้ assembly ของ CPU นั้นโดยตรง

// x86 assembly → C compiler สร้าง
add eax, ebx     ← ใช้ได้บน x86 เท่านั้น

// ARM assembly → คนละโลก
add r0, r0, r1   ← ใช้ได้บน ARM เท่านั้น

การจะ cross-compile C — คุณต้องมี cross-compiler toolchain:

Linux → ARM: ต้องติดตั้ง arm-linux-gnueabihf-gcc
macOS → Windows: ต้องติดตั้ง x86_64-w64-mingw32-gcc
แต่ละคู่ platform = toolchain ใหม่ — ติดตั้งครั้งละเป็นชั่วโมง

Rust: ใช้ LLVM เป็น backend — LLVM มี IR (Intermediate Representation) ของตัวเอง — ข้อดีคือ LLVM optimize เก่งมาก — แต่ LLVM เองเป็นโค้ด C++ มหาศาล — หนัก ช้า

Go เลือกทางสายกลาง: เขียน compiler backend เองทั้งหมด — ไม่ใช้ LLVM, ไม่ใช้ GCC, ไม่ใช้ toolchain ภายนอกเลยแม้แต่นิดเดียว

Mapping — แผนที่

Go เขียนโค้ด → คอมไพล์เป็น Plan 9 assembly (IR กลาง) → แล้วคอมไพล์ต่อเป็น machine code โดยตรง:

write.go (Go source)
    │
    ▼
[Go compiler frontend] → parse, type-check
    │
    ▼
Plan 9 assembly (IR กลาง — architecture-independent)
    │
    ├──→ [x86-64 backend]  → MOVQ, ADDQ, RET (Intel/AMD)
    ├──→ [ARM64 backend]   → MOV, ADD, RET   (Apple Silicon, Pi)
    ├──→ [ARM backend]     → MOV, ADD, RET   (Pi 32-bit)
    ├──→ [RISC-V backend]  → ...              (SiFive, etc.)
    └──→ [MIPS, s390x, ...]

ทุก backend อยู่ใน Go compiler เรียบร้อย — ไม่ต้องติดตั้งอะไรเพิ่ม

เปรียบเทียบ 3 ภาษา — ใครต้อง setup อะไรบ้าง

	Go	Rust	C/C++
Cross-compile ไป ARM	`GOARCH=arm go build`	`rustup target add` + linker	`apt install cross-gcc`
Backend	เขียนเอง (Go)	LLVM (C++)	GCC/LLVM
ขนาด toolchain	~100MB	~2GB+	~500MB-2GB
เวลา setup	0 (ติด Go แล้ว cross-compile ได้เลย)	5-10 นาที (add target)	1-3 ชม (หา toolchain, build)

ตัวอย่างจริง — ผมเคย cross-compile Go ให้ Raspberry Pi:

# บน Mac — สร้าง binary สำหรับ Raspberry Pi
GOOS=linux GOARCH=arm64 go build -o myapp-pi .

# copy ไป Pi
scp myapp-pi pi@raspberrypi:~

# รัน — ใช้ได้ทันที
ssh pi@raspberrypi ./myapp-pi

3 บรรทัด — ไม่ต้องหา ARM cross-compiler — ไม่ต้องติดตั้ง sysroot — เพราะ Go compiler มี ARM backend อยู่แล้ว — มันรู้ว่า ARM ใช้ instruction อะไร, register ชื่ออะไร, calling convention เป็นยังไง — ทุกอย่าง built-in

นี่คือเหตุผลที่ Go เป็นราชาแห่ง cross-compilation — ไม่ใช่เพราะมันมีฟีเจอร์วิเศษ — แต่เพราะมันไม่พึ่งพาใครเลย

ข้อที่ 6: Static Linking — ไม่ต้องพึ่งระบบ

Go compile เป็น static binary — รวมทุกอย่างไว้ในไฟล์เดียว:

$ ls -lh myapp
-rwxr-xr-x 8.2M myapp    # ← 8MB — ทั้ง app ในไฟล์เดียว

$ ldd myapp
not a dynamic executable  # ← ไม่พึ่งพา .so ใด ๆ

C/C++ ต้องทำอะไร? compile เป็น binary → ต้องมี libc.so, libstdc++.so, libpthread.so ฯลฯ — เปลี่ยน distro → พัง

Go: binary เดียว — copy ไปเครื่องไหนก็รันได้ — compile บน Mac, deploy บน Linux, รันบน Raspberry Pi — ง่ายมาก

ข้อที่ 7: Compiler เขียนด้วย Go — เร็วขึ้นเรื่อย ๆ

Go compiler ยุคแรกเขียนด้วย C — แต่ตั้งแต่ Go 1.5 (2015) — compiler เขียนด้วย Go เอง

นี่คือ "bootstrapping" — Go compile ตัวเอง — และทุกครั้งที่ Go เวอร์ชันใหม่เร็วขึ้น — compiler ก็เร็วขึ้นตาม

Go 1.0 (2012): compiler เขียนด้วย C
Go 1.5 (2015): compiler เขียนด้วย Go — ช้าลงเล็กน้อย
Go 1.7 (2016): compiler เร็วขึ้น 20-30% ด้วย SSA backend
Go 1.9 (2017): compiler เร็วขึ้นอีก
...
Go 1.22 (2024): compiler แทบจะ instantaneous สำหรับโปรเจกต์ขนาดกลาง

ข้อที่ 8: Grammar Simplicity — อ่านโค้ดรอบเดียวจบ

Go แตกต่างจาก C++ ตรงที่ ไวยากรณ์ถูกออกแบบมาเพื่อ compiler — ไม่ใช่เพื่อโปรแกรมเมอร์ที่ชอบความซับซ้อน

Hand-Written Recursive Descent — parser ที่มนุษย์เขียนเอง

Go ใช้ hand-written recursive descent parser — คือ parser ที่เขียนด้วยมือ ไม่ได้ generate จาก grammar (ต่างจาก yacc/bison ที่ใช้ใน C compiler หลายตัว)

การเขียน parser ด้วยมือมีข้อดี: compiler ควบคุมทุกอย่างได้ — ไม่มี overhead จาก table-driven parsing — และ error message อ่านรู้เรื่องเพราะมนุษย์เขียนเอง

📜 เกร็ดประวัติศาสตร์: Go 1.0-1.4 ใช้ yacc (ซึ่งใช้ LALR(1)) สำหรับบางส่วนของ parser — แต่ตั้งแต่ Go 1.5 ที่ compiler ถูก rewrite ด้วย Go ทั้งหมด — parser เปลี่ยนเป็น hand-written recursive descent เต็มตัว

แต่ไม่ว่าจะใช้ yacc หรือ recursive descent — หัวใจสำคัญคือ Go grammar ถูกออกแบบให้ ง่ายพอที่ parser แบบไหนก็ทำงานได้ใน single pass

// ทุกประโยคใน Go — compiler รู้ทันทีว่าคืออะไร
func Add(a, b int) int {    // ← function declaration — ไม่ใช่อย่างอื่น
    return a + b
}

x := Add(1, 2)              // ← short variable declaration — ชัดเจน
var y int = Add(3, 4)       // ← variable declaration — var นำหน้า

compiler ไม่ต้องถามว่า "นี่คือ function call หรือ variable declaration?" — เพราะ syntax บังคับให้เดาไม่ได้

C++: Most Vexing Parse — compiler เองก็สับสน

// C++ — Most Vexing Parse: compiler ไม่รู้ว่านี่คืออะไร
Widget w();  // ❓ function declaration (คืนค่า Widget) — หรือ variable declaration?
             // คำตอบ: มันคือ function declaration! (Most Vexing Parse)

Widget w{};  // ✅ variable declaration — ใช้ {} แทน

นี่คือตัวอย่างของ context-sensitive grammar ใน C++ — compiler ต้องดูบริบทว่ามี type ชื่อ Widget ไหม — มี constructor แบบไหน — มันคือ function หรือ variable — ทั้งหมดนี้ใช้เวลา CPU มหาศาล

ตารางเทียบ — อะไรทำให้ Go ง่าย C++ ยาก

	Go	C++
Grammar complexity	ออกแบบให้ unambiguous — parser เลือกใช้ได้ (yacc หรือ recursive descent)	Context-sensitive — parser ต้องเดาจากบริบท
Parsing	Single-pass — รอบเดียวจบ	Multiple-pass + template instantiation
Preprocessor	❌ ไม่มี	✅ `#include`, `#define`, `#ifdef`
Forward declaration	❌ ไม่ต้อง — order อิสระ	✅ ต้อง — `class A;`
Template	❌ (generics 1.18+ เป็นคนละเรื่อง)	✅ template metaprogramming
Compile-time computation	❌	✅ `constexpr`, SFINAE

ทำไม Go ถึงไม่มี preprocessor?

Preprocessor ใน C/C++ ทำให้ compiler ต้องทำงาน 2 รอบ:

source.c → [preprocessor: expand #include, #define] → expanded.c → [compiler]

ทุกไฟล์ .c ผ่าน preprocessor → ขยายเป็นไฟล์ใหญ่ยักษ์ → ส่งให้ compiler จริง — นี่คือ 2x งาน

Go: source code → compiler โดยตรง — ไม่มีขั้นกลาง — 1 pass, 1 job

ผลลัพธ์ในโลกจริง

Kubernetes (Go):      ~3 ล้านบรรทัด — compile ทั้งโปรเจกต์ใน ~2 นาที
Chromium (C++):      ~35 ล้านบรรทัด — compile ใช้เวลา 30-60 นาที (แม้ใช้ distributed build!)

สัดส่วน: Kubernetes มีโค้ด 1/10 ของ Chromium — แต่ compile เร็วกว่า 15-30 เท่า — ไม่ใช่แค่เพราะขนาดเล็กกว่า — แต่เพราะ Go compiler ถูกออกแบบมาให้ "เร็ว" ตั้งแต่แรก

📊 สรุป — อะไรทำให้ Go compile ไว

ปัจจัย	ทำอะไร	ทำไมถึงเร็ว
ไม่มี Header Files	อ่าน `.go` ตรง	compiler ไม่ต้องไล่ `#include` chain
DAG Dependency	ห้าม circular import	เรียงลำดับ compile ได้, parallel ได้
Unused Import = Error	compiler ไม่โหลด package ที่ไม่ใช้	ลดงาน compiler
Object Files อัจฉริยะ	`.a` มีข้อมูลครบ	ไม่ต้องเปิด source หา dependency
Plan 9 Assembly	IR กลาง	cross-compile ได้ทันที โดยไม่ต้อง toolchain ใหม่
Static Linking	binary ในไฟล์เดียว	deploy ง่าย ไม่พึ่งระบบ
Compiler เขียนด้วย Go	bootstrapping	compiler เร็วขึ้นทุกเวอร์ชัน
Simple Grammar	hand-written parser, ไม่มี preprocessor, single-pass	ไม่ต้อง parse ซ้ำ, ไม่คลุมเครือ

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

ไม่ใช่แค่ "compile ไว = สะดวก" — แต่มันเปลี่ยน วิธีคิด

C++: compile → รอ 5 นาที → เช็คมือถือ → ลืมว่าทำอะไรอยู่
Go:  compile → 2 วิ → test → แก้ → compile → test → flow

Fast feedback loop คือ superpower — คุณทดลองได้เร็ว, กล้า refactor, ไม่กลัว compile error — เพราะมันใช้เวลาแค่ 2 วิ

นี่คือสิ่งที่ Ken Thompson, Rob Pike, และ Robert Griesemer ตั้งใจ — ไม่ใช่แค่ "สร้างภาษาใหม่" — แต่คือการสร้าง ประสบการณ์ ใหม่ในการเขียนโปรแกรม

📚 อ่านต่อ:

Go at Google: Language Design in the Service of Software Engineering — Rob Pike (2012)

The Go Programming Language — Donovan & Kernighan

Go FAQ: Why does Go compile so quickly?

Agent Skills — Taxonomy ฉบับสมบูรณ์ของ Claude Code

Gophernment — Sun, 05 Jul 2026 07:48:22 +0000

Agent Skills — Taxonomy ฉบับสมบูรณ์ของ Claude Code

ตอนใช้ Claude Code ครั้งแรก — เรามักเข้าใจว่า "ทุกอย่างอยู่ใน CLAUDE.md"

แต่พอใช้ไปสักพัก — เราเริ่มเจอของแปลก: /deploy ทำงานได้เอง, มี hook ตรวจจับตอนเซฟไฟล์, มี subagent ที่ spawn ไปทำงานแล้วกลับมาบอกผล

"นี่มันไปเอาคำสั่งพวกนี้มาจากไหน?"

Claude Code มีระบบ instruction ที่เป็น ชั้น ๆ (layers) — ไม่ใช่แค่ CLAUDE.md ไฟล์เดียว — แต่มันคือ 4 กลุ่มใหญ่ 20+ กลไก ที่ทำงานใน persistence model ต่างกัน

4 Persistence Models — ไม่ใช่แค่ One-Shot กับ Persistent

Model	หลักการ	ตัวอย่าง
🔒 Persistent	ตั้งครั้งเดียว อยู่ทุก session	CLAUDE.md, settings, skills
🔄 Context-Triggered	โหลดเมื่อบริบทตรงเงื่อนไข	Path-scoped rules, nested CLAUDE.md
⚡ Event-Driven	ทำงานอัตโนมัติเมื่อเหตุการณ์เกิด	Hooks (30+ event types)
🎯 Session-Bound	อยู่แค่ session นี้	CLI flags, env vars, conversation

🔒 กลุ่มที่ 1: Persistent — ตั้งครั้งเดียว อยู่ทุก Session

นี่คือ "กระดูกสันหลัง" ของ Claude Code — โหลดทุก session โดยคุณไม่ต้องทำอะไร

CLAUDE.md — 4 ระดับ

ลำดับ	ตำแหน่ง	Scope	ใช้สำหรับ
1	`/etc/claude-code/CLAUDE.md` (Linux)	ทั้งองค์กร	นโยบายความปลอดภัย, มาตรฐานบริษัท
2	`~/.claude/CLAUDE.md`	ส่วนตัว	ความชอบ, ทางลัดเครื่องมือ
3	`./CLAUDE.md`	โปรเจกต์	สถาปัตยกรรม, มาตรฐานโค้ด
4	`./CLAUDE.local.md`	ส่วนตัว+โปรเจกต์	ข้อมูลทดสอบ, URL sandbox

หลักการ: โหลดจาก scope กว้าง → แคบ — คำสั่งโปรเจกต์ override คำสั่งผู้ใช้

# ./CLAUDE.md
## Stack: Go 1.22+, PostgreSQL, chi router
## Rules:
- Interface at consumer
- Error: %w wrapping
- Test: table-driven + httptest

Skills — คลังคำสั่งที่เรียกใช้เมื่อต้องการ

.claude/skills/<name>/SKILL.md

---
description: "Generate database migration files"
model: claude-haiku-4-5      # ใช้ model ถูกเพื่องานง่าย
tools: [read_file, write_file]
---
1. Ask for table name and fields
2. Create timestamped SQL file in db/migrations/
3. Include both UP and DOWN migration

เรียกใช้ด้วย /migration — หรือ Claude auto-detect จาก context

Auto Memory — Claude เขียนบันทึกเอง

คุณแค่บอกว่า "จำไว้ว่าใช้ go test -race เสมอ" — Claude เขียนลง ~/.claude/projects/<name>/memory/ — ครั้งหน้ามันจะจำได้

CLAUDE.md: คุณเขียน | Auto Memory: Claude เขียน
CLAUDE.md: กฎและมาตรฐาน | Auto Memory: สิ่งที่เรียนรู้

Settings — ควบคุมพฤติกรรม

ไฟล์	Scope
`~/.claude/settings.json`	ผู้ใช้ (ทุกโปรเจกต์)
`.claude/settings.json`	โปรเจกต์
`.claude/settings.local.json`	โปรเจกต์ (ส่วนตัว)

{
  "permissions": {
    "allow": ["Bash(npm test:*)", "Read(~/*)"],
    "deny": ["Bash(rm:*)", "Write(/etc/*)"]
  }
}

🔄 กลุ่มที่ 2: Context-Triggered — โหลดเฉพาะเมื่อจำเป็น

นี่คือ skills ที่ "ฉลาด" — ไม่โหลดเข้าทุก session — แต่โหลดเมื่อบริบทตรงเงื่อนไข

Path-Scoped Rules

.claude/rules/api-design.md
.claude/rules/css-styling.md

Claude จะโหลด api-design.md เมื่อทำงานกับไฟล์ใน src/api/ — และไม่โหลด css-styling.md ถ้าคุณไม่ได้แตะ CSS

# .claude/rules/api-design.md
## When: working in src/api/**/*.go
- Always return JSON with `{data, error}` envelope
- Rate limit: 100 req/min per user
- Use `context.Context` for cancellation

Nested CLAUDE.md

project/
├── CLAUDE.md            ← โหลดเสมอ
├── backend/
│   └── CLAUDE.md        ← โหลดเมื่อเข้าถึง backend/
└── frontend/
    └── CLAUDE.md        ← โหลดเมื่อเข้าถึง frontend/

ใช้สำหรับ monorepo — แต่ละ sub-project มี context ของตัวเอง

Skill Content — โหลดเมื่อเรียกใช้

Skills metadata (ชื่อ + description) อยู่ใน context ตลอด — แต่เนื้อหาเต็มของ skill โหลดเฉพาะตอน /skill หรือตอน Claude auto-detect

⚡ กลุ่มที่ 3: Event-Driven — ทำงานอัตโนมัติเมื่อเหตุการณ์เกิด

นี่คือ layer ที่ทรงพลังที่สุด — และคนส่วนใหญ่ไม่รู้ว่ามี

Hooks — 30+ Event Types

กลุ่ม	Events
🔵 Session	SessionStart, Setup, PreCompact, PostCompact, SessionEnd
🟢 User	UserPromptSubmit, MessageDisplay
🟡 Tool	PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest
🟠 Subagent	SubagentStart, SubagentStop
🔴 System	Notification, ConfigChange, FileChanged

ตัวอย่าง Hook: "ก่อน Claude จะรัน git push — รัน test ก่อนเสมอ"

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git push:*)",
        "command": "npm test && npm run build"
      }
    ]
  }
}

5 ประเภท Handler:

Handler	ใช้เมื่อ
Command	Shell script (รับ JSON stdin)
HTTP	เรียก API ภายนอก
Prompt-based	ใช้ LLM ตรวจสอบ semantic
Agent-based	งานซับซ้อนหลายขั้นตอน
MCP tool	เชื่อมต่อเครื่องมือ MCP

Subagents — ตัวแทนย่อย

.claude/agents/reviewer.md
.claude/agents/tester.md

---
description: "Code reviewer — checks Go idioms and naming"
model: claude-haiku-4-5
tools: [read_file, grep, glob]
---
You review Go code for:
- Interface at consumer, not producer
- Error wrapping with %w
- Table-driven tests

Claude จะ spawn subagent ไปทำงาน — ผลลัพธ์ไม่เข้า context window ของ parent — ประหยัด token

🎯 กลุ่มที่ 4: Session-Bound — อยู่แค่ Session นี้

กลไก	ตัวอย่าง
CLI Flags	`--model claude-opus-4-8`, `--permission-mode plan`
Env Vars	`ANTHROPIC_API_KEY`, `CLAUDE_CODE_MODEL`
Output Styles	`/config` → เลือก Default/Proactive/Explanatory/Learning
Inline Memory	`/memory` → แก้ไขระหว่าง session
Conversation	การสนทนาทั้งหมดใน session นี้

📊 ลำดับการโหลด — เกิดอะไรขึ้นตอน Claude Code เริ่มทำงาน

1. SYSTEM PROMPT (built-in)
   └── Output style ปรับแต่ง

2. CLAUDE.MD (เรียงลำดับ)
   └── Managed → User → Project → Local

3. AUTO MEMORY
   └── 200 บรรทัดแรก

4. SKILLS METADATA
   └── ชื่อ + description

5. MCP TOOLS
   └── Tool definitions

6. HOOKS FIRE
   └── SessionStart → Setup → InstructionsLoaded

7. USER PROMPT
   └── ข้อความแรกจากคุณ

📦 ติดตั้ง Skills จากข้างนอก — เราได้อะไรมาบ้าง?

คำสั่งยอดนิยมที่เห็นใน community:

npx skills@latest add mattpocock/skills

หรือจาก marketplace อื่น:

claude plugin install <name>@<marketplace>

ได้อะไรมาบ้าง? — มันไม่ใช่แค่ "skill" ธรรมดา

mattpocock/skills (157K ⭐ บน GitHub) คือ Claude Code Plugin — ไม่ใช่แค่ไฟล์ skill เดียว — แต่มันคือ package ที่รวมทุก layer ใน taxonomy พร้อมกัน:

สิ่งที่ได้	อยู่ในโฟลเดอร์	คือ layer ไหน
Skills (`/review`, `/test`, `/plan`)	`.claude-plugin/` → skills	Persistent
Subagents (code-reviewer, tester)	`.agents/`	Event-Driven
Hooks (auto-format, lint on save)	`.claude-plugin/` → hooks	Event-Driven
Commands	`.claude-plugin/` → commands	Persistent

สรุป: การ install ครั้งเดียว — ได้ทั้ง skills, subagents, hooks, commands — ครบทุก layer

ตรวจสอบว่าได้อะไรมาบ้าง

# 1. ดู skills ทั้งหมดที่มี (รวมที่ติดตั้งจาก plugin)
ls .claude/skills/
ls ~/.claude/skills/

# 2. ดู plugin ที่ติดตั้ง
claude plugin list
# หรือ
ls ~/.claude/plugins/

# 3. ใน Claude Code — ลองเรียก
/skill-name      # เรียกใช้ skill โดยตรง

# 4. ดูว่า subagent ใหม่มีอะไรบ้าง
ls .claude/agents/
ls ~/.claude/agents/

# 5. ดู hooks ที่เพิ่มมา
cat .claude/settings.json | grep -A 20 hooks

ติดตั้งแล้วอยู่ตรงไหน?

mattpocock/skills (GitHub repo)
       │
       ▼  npx skills@latest add
       │
~/.claude/plugins/<name>/
       │
       ├── skills/          → ปรากฏเป็น /skill-name
       ├── agents/          → ปรากฏเป็น subagent
       ├── hooks/           → ปรากฏใน settings hooks
       └── commands/        → ปรากฏเป็น /command

ระวังอะไรบ้าง

Plugin อาจ override settings ของคุณ — ตรวจสอบว่ามันแก้ settings.json หรือไม่
ดู source ก่อน install — plugin มีสิทธิ์รัน shell commands ผ่าน hooks
ลองใน project test ก่อน — อย่าเพิ่งลงใน project production
อัปเดตเรื่อย ๆ — @latest ดึงเวอร์ชันล่าสุด

สรุป — เลือกใช้ Layer ให้ถูก

อยากทำ...	ใช้...	เพราะ...
บอก Claude ว่า project ใช้ Go	`./CLAUDE.md`	โหลดทุก session
เพิ่มกฎเฉพาะ API	`.claude/rules/api.md`	โหลดเมื่อแตะ API
ตรวจสอบก่อน push	Hook `PreToolUse`	ทำงานอัตโนมัติ
สร้าง migration file	`/migration` skill	เรียกเมื่อต้องการ
ให้ Claude จำ pattern	Auto Memory	Claude เขียนเอง
บล็อก `rm -rf`	`settings.json`	deny rule ถาวร
ใช้ model ถูกเพื่องาน review	Subagent + `model:` field	แยก context

📚 อ่านต่อ:

Claude Code: Settings & CLAUDE.md

Claude Code: Hooks

Claude Code: Skills

Claude Code: Subagents

📅 เขียนเมื่อ: กรกฎาคม 2026 | Claude Code v1.x
⚠️ ข้อมูลอ้างอิงจากเอกสารทางการของ Anthropic — features อาจมีการเปลี่ยนแปลง