DEV Community: Gophernment Co

เขียน Go แบบ Java/Ruby/PHP — ทางลัดสู่ Technical Debt โดยไม่รู้ตัว

Gophernment Co — Mon, 29 Jun 2026 11:09:46 +0000

เขียน Go แบบ Java/Ruby/PHP — ทางลัดสู่ Technical Debt โดยไม่รู้ตัว

มีเรื่องเล่าใน community Go ว่าเคยมีคนเขียนโค้ดแบบนี้ส่งมาที่ code review:

type UserGetterServiceInterface interface {
    GetUser(id string) (*User, error)
}

type UserGetterService struct {
    repo UserRepositoryInterface
}

func NewUserGetterService(repo UserRepositoryInterface) *UserGetterService {
    return &UserGetterService{repo: repo}
}

แล้วคนรีวิวถามว่า "พี่ครับ... อะไรคือ UserGetterServiceInterface? แล้วทำไมต้องมี NewUserGetterService?"¹

เจ้าตัวตอบแบบซื่อ ๆ ว่า "ก็ผมมาจาก Java นี่นา"

ปัญหาไม่ได้อยู่ที่ภาษา — อยู่ที่ "สำเนียง"

เวลาเราเรียนรู้ภาษาใหม่ — โดยเฉพาะภาษาแรกหรือภาษาที่สอง — เรามักจะเขียนมันด้วย "สำเนียง" ของภาษาเดิม ฝรั่งเรียกปรากฏการณ์นี้ว่า accent-driven development

ถ้าคุณมาจาก...	คุณมักจะ...
☕ Java	สร้าง interface ทุกอย่าง, factory pattern, getter/setter, inheritance
💎 Ruby	metaprogramming, monkey-patching, magic method, `method_missing`
🐘 PHP	global state, framework-first mindset, procedural ใน struct
🐍 Python	exception for control flow, decorator ซ้อน decorator, `__init__` magic

ทั้งหมดนี้ไม่ใช่ของไม่ดี — แต่มันคือ "เครื่องมือของอีกภาษา" พอเอามาใช้ใน Go โดยไม่ปรับ mindset — มันกลายเป็น code ที่อ่านยาก, ช้า, และที่สำคัญคือ ไม่ใช่ Go

☕ Java → Go: OOP Overdose

นี่คือกลุ่มที่เจอบ่อยที่สุด เพราะคนเขียน Java เยอะ และ Go ถูกใช้แทนที่ Java ใน microservices พอดี

Interface ทุกอย่าง — "เผื่อไว้"

// ❌ สำเนียง Java — interface ที่มี implementation เดียว
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    Save(ctx context.Context, user *User) error
}

type PostgresUserRepo struct { db *sql.DB }
// ... implement ทั้งสอง method

func NewUserService(repo UserRepository) *UserService { ... }

ใน Java คุณต้องมี interface เพราะ DI framework (Spring) ต้องการมัน และเพราะการ mock ใน Java ทำผ่าน interface

ใน Go — interface ถูกใช้ต่างกันโดยสิ้นเชิง:

"The bigger the interface, the weaker the abstraction."²

Go interfaces should be:

เล็ก (1-3 methods)
ประกาศฝั่ง consumer (คนใช้), ไม่ใช่ฝั่ง producer (คนสร้าง)
ใช้เมื่อมีอย่างน้อย 2 implementations — ไม่ใช่ "เผื่อไว้"

// ✅ วิธี Go — ประกาศ interface ที่ consumer
// user_service.go
type userFinder interface {
    FindByID(ctx context.Context, id string) (*User, error)
}

type UserService struct {
    users userFinder // ← interface เกิดตรงนี้ — เล็ก, ใช้จริง
}

// user_repo.go — ฝั่งนี้ไม่มี interface เลย
type UserRepo struct { db *sql.DB }

func (r *UserRepo) FindByID(ctx context.Context, id string) (*User, error) { ... }

แบบนี้มีข้อดี:

interface เกิดที่คนใช้ → คนใช้บอกเองว่าอยากได้แค่ FindByID ไม่เอาทั้ง Save, Delete, Update³
ไม่ต้องมี mock framework — แค่สร้าง struct{ FindByID func(...) } ก็ test ได้
อ่านโค้ดรู้ทันทีว่า service ใช้แค่ find — ไม่ได้ใช้ save

Getter/Setter ทุก field — "เผื่อมี logic ภายหลัง"

// ❌ สำเนียง Java — getter/setter ทั้งที่ field เป็น public อยู่แล้ว
type User struct {
    name  string
    email string
}

func (u *User) GetName() string  { return u.name }
func (u *User) SetName(n string) { u.name = n }
func (u *User) GetEmail() string { return u.email }
func (u *User) SetEmail(e string) { u.email = e }

ใน Java คุณทำแบบนี้เพราะ:

Bean convention — framework จะเรียก getXxx() / setXxx() อัตโนมัติ
Encapsulation — เผื่อมี logic ใน getter/setter วันข้างหน้า

ใน Go — YAGNI⁴:

// ✅ Go — field คือ field, อย่า wrap โดยไม่จำเป็น
type User struct {
    Name  string
    Email string
}

ถ้าวันข้างหน้ามี logic จริง ๆ — ค่อยเปลี่ยนเป็น method ตอนนั้น compiler จะฟ้องทุกที่ที่ใช้ user.Name ทำให้ refactor ปลอดภัย

"Architecture" ก่อนเขียนโค้ด

// ❌ สำเนียง Java — โครงสร้างโฟลเดอร์ที่มาก่อนปัญหา
myapp/
├── controller/
│   └── user_controller.go
├── service/
│   ├── user_service.go
│   └── user_service_interface.go
├── repository/
│   ├── user_repository.go
│   └── user_repository_interface.go
├── model/
│   └── user.go
├── dto/
│   └── user_dto.go
└── util/
    └── string_util.go

สำหรับ Go — เริ่มจาก flat structure ก่อน:

// ✅ Go — เริ่มเรียบ ๆ, แยกเมื่อจำเป็น
myapp/
├── main.go
├── user.go          // User struct + UserRepo + UserService
├── user_test.go
└── handler.go       // HTTP handlers

พอโปรเจกต์ใหญ่ขึ้นก็ค่อยแยก package — แต่ไม่ใช่เพราะ "architecture บอกว่าต้องแยก" — แต่เพราะโค้ดเรียกร้องให้แยก⁵

💎 Ruby → Go: Magic มากเกิน

คน Ruby โดยเฉพาะ Rails dev — คุ้นเคยกับ "convention over configuration" และ metaprogramming

`method_missing` ใน Go — ไม่มีวันได้

# Ruby — dynamic method
class User
  def method_missing(name, *args)
    if name.to_s.start_with?("find_by_")
      field = name.to_s.sub("find_by_", "")
      # ... query database
    end
  end
end

User.new.find_by_email("a@b.com") # Magic!

ใน Go — ไม่มีทาง:

// Go — explicit methods เท่านั้น
func (r *UserRepo) FindByEmail(ctx context.Context, email string) (*User, error) {
    // เขียนเองทีละ method — ชัดเจน, grep ได้, IDE autocomplete ได้
}

หลายคนที่ย้ายมาจาก Ruby จะรู้สึกว่า Go "verbose" — แต่นั่นคือ feature ไม่ใช่ bug: โค้ด Go อ่านแล้วรู้ทันทีว่าทำอะไร โดยไม่ต้องรันก่อน

`nil` ≠ `nil` — หลุมพรางที่ Ruby dev มองข้าม

ใน Ruby — nil คือ nil:

user = nil
puts user.name if user  # ไม่พัง

ใน Go — nil มี type:

// ❌ bug คลาสสิก
func GetUser() *User {
    return nil // ← nil pointer to User
}

func GetError() error {
    return (*MyError)(nil) // ← ไม่ใช่ nil error! เป็น non-nil interface
}

// เทียบกัน
u := GetUser()
fmt.Println(u == nil) // true

e := GetError()
fmt.Println(e == nil) // false! — เพราะ interface มี type แต่ว่า nil

นี่คือหลุมพรางที่ Ruby dev เจอเกือบทุกคน — interface ใน Go ประกอบด้วย (type, value) ไม่ใช่แค่ value⁶

🐘 PHP → Go: Frameworks First

ทุกอย่างต้องมี framework

// PHP — Laravel
Route::get('/users/{id}', [UserController::class, 'show']);

// ❌ สำเนียง PHP — ตามหา "Go framework" ที่เหมือน Laravel
import "github.com/someone/goravel"

ใน Go — stdlib net/http ก็พอแล้ว:

// ✅ Go — router ใน 3 บรรทัด
mux := http.NewServeMux()
mux.HandleFunc("GET /users/{id}", handleGetUser)
http.ListenAndServe(":8080", mux)

Go 1.22+ รองรับ method-based routing ใน stdlib แล้ว ไม่ต้องหา framework เล็ก ๆ มาทำเรื่องนี้⁷

Global state

PHP dev คุ้นเคยกับการใช้ global:

// PHP
$db = new PDO("...");
function getUser($id) {
    global $db;
    return $db->query("...");
}

ใน Go — injection คือคำตอบ:

// ✅ Go — dependency injection ผ่าน constructor ง่าย ๆ
type Handler struct {
    svc *UserService
}

func NewHandler(svc *UserService) *Handler {
    return &Handler{svc: svc}
}

func (h *Handler) GetUser(w http.ResponseWriter, r *http.Request) {
    user, err := h.svc.GetUser(r.Context(), "42")
    // ...
}

ไม่ต้องมี DI framework — แค่ส่ง *UserService เข้า constructor ก็ได้ละ

🐍 Python → Go: Exception Mindset

Error คือ Exception

# Python — try/except
def get_user(id):
    try:
        return db.query(f"SELECT * FROM users WHERE id = {id}")
    except DatabaseError:
        return None

// ❌ สำเนียง Python — panic แทน return error
func GetUser(id string) *User {
    user, err := db.Query(...)
    if err != nil {
        panic(err) // ❌ อย่าทำ! Go ไม่ได้ใช้ panic เป็น control flow
    }
    return user
}

Go — error คือ value:

// ✅ Go — return error, ให้ caller จัดการ
func GetUser(ctx context.Context, id string) (*User, error) {
    user, err := db.QueryRow(ctx, "SELECT * FROM users WHERE id = $1", id)
    if err != nil {
        return nil, fmt.Errorf("GetUser: %w", err)
    }
    return user, nil
}

Decorator ซ้อน Decorator

# Python
@login_required
@validate_params
@cache_result(ttl=300)
def get_user(id):
    ...

// ✅ Go — middleware chain — ชัดเจนว่าอะไรเกิดก่อน-หลัง
func handleGetUser(w http.ResponseWriter, r *http.Request) { ... }

// ใน main:
handler := middleware.Chain(
    handleGetUser,
    middleware.LogRequest,
    middleware.RequireAuth,
    middleware.ValidateParams,
    middleware.CacheResult(5*time.Minute),
)

ต่างกันที่ — ใน Go คุณเห็นลำดับชัดเจน (ข้างใน → ข้างนอก) — ใน Python มันซ้อนกันจากบนลงล่าง ทำให้ debug ลำบากเวลามี middleware หลายตัว

สรุป — เรียนรู้ Grammar ไม่พ้อง ต้องเรียนรู้ "สำเนียง"

สำเนียงเดิม	อาการที่พบบ่อย	ทางแก้
☕ Java	interface ทั้งที่ใช้ implementation เดียว	interface เล็ก ประกาศที่ consumer
☕ Java	getter/setter ครอบ field เปล่า ๆ	field คือ field, refactor ทีหลัง
☕ Java	โฟลเดอร์แยกตาม layer ก่อนเขียนโค้ด	เริ่ม flat, แยกเมื่อจำเป็น
💎 Ruby	พยายาม metaprogramming	Go = explicit, embrace it
💎 Ruby	`nil` ไม่ระวัง type	เข้าใจว่า interface nil ≠ pointer nil
🐘 PHP	ตามหา framework	net/http พอ, Go 1.22+ มี routing ในตัว
🐘 PHP	global state	dependency injection ผ่าน constructor
🐍 Python	panic = exception	error คือ value, return มัน
🐍 Python	decorator ซ้อน decorator	middleware chain — ชัดเจนกว่า

วิธีแก้ — อ่าน Effective Go

หลังจากเขียน Go มาได้สักเดือน — ผมแนะนำให้อ่าน Effective Go หนึ่งรอบ

มันคือ "สำเนียง" ทางการของ Go — ไม่ใช่แค่ syntax — แต่มันสอนวิธีคิด: ทำไมใช้ := ตรงนี้, ทำไม interface ต้องเล็ก, ทำไม init() ใช้แค่เมื่อจำเป็น

และอีกเรื่องที่ช่วยได้มาก: อ่านโค้ด standard library⁸ — net/http, encoding/json, database/sql — โค้ดพวกนี้คือตัวอย่างของ "สำเนียง Go" ที่ดีที่สุด

เชิงอรรถ

"NewXxx" vs "xxxBar": ใน Go — constructor มักชื่อ NewXxx — แต่ใช้เฉพาะเมื่อมันมี logic เช่น validate input หรือตั้งค่า default — ไม่ใช่แค่ return &Xxx{} เปล่า ๆ ↩
"The bigger the interface, the weaker the abstraction" — Rob Pike, Go Proverbs — https://go-proverbs.github.io ↩
Interface ที่ consumer: นี่คือหนึ่งในแนวคิดที่แตกต่างจาก Java มากที่สุด — ใน Java, interface ถูกประกาศโดย library owner ใน Go, interface ถูกประกาศโดย library user — ทำให้ dependency กลับทิศ, สะอาดกว่า ↩
YAGNI: "You Aren't Gonna Need It" — หลักการออกแบบที่บอกว่าอย่าเขียนโค้ดสำหรับ requirement ที่ยังไม่มี — เพราะ requirement มักเปลี่ยน หรือไม่เกิดเลย ↩
Package structure: มี talk ชื่อดังโดย Ben Johnson ชื่อ "Standard Package Layout" — https://www.gobeyond.dev/standard-package-layout/ ↩
Interface nil ≠ pointer nil: interface ใน Go เก็บ (type, value) เป็น tuple — (*MyError)(nil) มี type = *MyError แต่ value = nil — interface โดยรวมไม่ใช่ nil อ่านเพิ่ม: https://go.dev/doc/faq#nil_error ↩
Go 1.22 routing: http.ServeMux รองรับ GET /users/{id} ตั้งแต่ Go 1.22 — https://go.dev/blog/routing-enhancements ↩
อ่าน standard library: Go standard library คือ textbook ที่ดีที่สุด — เขียนโดยคนเดียวกันกับที่ออกแบบภาษา มันคือ "สำเนียง Go" ที่ถูกต้องและสะอาดที่สุดที่มีอยู่ ↩

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

Gophernment Co — Mon, 29 Jun 2026 10:31:35 +0000

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

หรือที่ฝรั่งเรียกกันว่า "log and return" anti-pattern

เคยเจอไหม? เปิด log มาดู error เดียวกันซ้ำ 3-4 บรรทัด ทั้งที่มันคือ error จากเหตุการณ์เดียวกัน เขียนโค้ดดี ๆ แต่ log ดูกระจายเหมือนเกิดแผ่นดินไหว

นี่คือ Double Report — anti-pattern ยอดฮิตที่เกิดขึ้นใน Go (และภาษาอื่น) เวลาที่เราไม่แน่ใจว่า "ควร log ตรงไหน" แล้วก็เลย... log ทุกที่

ปัญหาหน้าตาเป็นยังไง

ลองดูตัวอย่าง — REST API ที่ query user จาก database:

// repository/user.go
func (r *UserRepo) FindByID(ctx context.Context, id string) (*User, error) {
    user, err := r.db.QueryRow(ctx, "SELECT * FROM users WHERE id = $1", id)
    if err != nil {
        log.Printf("failed to query user: %v", err) // ❌ log ครั้งที่ 1
        return nil, fmt.Errorf("FindByID: %w", err)
    }
    return user, nil
}

// service/user.go
func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
    user, err := s.repo.FindByID(ctx, id)
    if err != nil {
        log.Printf("error getting user %s: %v", id, err) // ❌ log ครั้งที่ 2
        return nil, fmt.Errorf("GetUser: %w", err)
    }
    return user, nil
}

// handler/user.go
func (h *UserHandler) GetUser(w http.ResponseWriter, r *http.Request) {
    id := chi.URLParam(r, "id")
    user, err := h.svc.GetUser(r.Context(), id)
    if err != nil {
        log.Printf("handler GetUser failed: %v", err) // ❌ log ครั้งที่ 3
        http.Error(w, "not found", http.StatusNotFound)
        return
    }
    json.NewEncoder(w).Encode(user)
}

Log ที่ออกมา:

2026/06/29 17:00:01 failed to query user: connection refused
2026/06/29 17:00:01 error getting user 42: FindByID: connection refused
2026/06/29 17:00:01 handler GetUser failed: GetUser: FindByID: connection refused

error จริงมีแค่ connection refused — แต่ log เป็นสามบรรทัด วนซ้ำ context เดิม สิ่งที่เกิดขึ้นคือเราโปะ context เพิ่ม (FindByID:, GetUser:) แล้ว log ทุกระดับ ผลลัพธ์ = noise

ลองนึกภาพ production ที่มี request พร้อมกันเป็นร้อย — log จะอ่านยากขนาดไหน

ทำไมเราถึงเผลอทำ

มันมาจาก mindset นี้:

"ไม่รู้ว่า caller จะ handle error ยังไง — log ไว้ก่อนดีกว่า เผื่อหาย"

แต่ใน Go error คือ value¹ — มันถูกส่งกลับขึ้นไปตาม call chain อยู่แล้ว คนเรียกมีสิทธิ์เต็มที่ที่จะตัดสินใจว่าจะ log, wrap, ignore, หรือเปลี่ยนเป็น error type อื่น

พอเรา log ทุกชั้น — เรากำลังแย่งหน้าที่ของ caller โดยไม่จำเป็น

วิธีที่ถูกต้อง — Log หรือ Return อย่างใดอย่างหนึ่ง

กฎง่าย ๆ ที่ community Go ยึดกัน:

Either log the error, or return it — never both²

แปลคือ: ในหนึ่งชั้นของ call chain — คุณเลือกทำอย่างใดอย่างหนึ่ง:

Log แล้ว swallow — เมื่อคุณจัดการ error ได้เรียบร้อยแล้ว และไม่อยากให้มันไปต่อ
Return error — เมื่อคุณยังจัดการไม่ได้ อยากให้คนเรียกตัดสินใจ

แก้ที่ Repository — return เฉย ๆ, ไม่ต้อง log

Repository เป็น layer ต่ำสุด — มันไม่รู้ว่า error เกิดจากอะไร, มีผลกระทบยังไง, ควร log ที่นี่ไหม มันก็แค่ return:

func (r *UserRepo) FindByID(ctx context.Context, id string) (*User, error) {
    user, err := r.db.QueryRow(ctx, "SELECT * FROM users WHERE id = $1", id)
    if err != nil {
        return nil, fmt.Errorf("FindByID: %w", err)
    }
    return user, nil
}

fmt.Errorf("FindByID: %w", err) — อันนี้คือ wrapping ไม่ใช่ logging นะ — มันเติมชื่อ function เข้าไปใน error chain เพื่อให้ debug ได้³ โดยไม่ต้อง log

แก้ที่ Service — business logic ตรงนี้

Service รู้บริบท: "หา user id 42 ไม่เจอมันแปลว่า not found หรือ database down?" — นี่คือที่ที่ควร log:

func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
    user, err := s.repo.FindByID(ctx, id)
    if err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            return nil, fmt.Errorf("user %s not found", id)
        }
        // ⚠️ database connection error — service เห็นว่ามันคือ infra issue
        slog.Error("database error", "user_id", id, "error", err)
        return nil, fmt.Errorf("GetUser: %w", err)
    }
    return user, nil
}

สังเกตว่า:

sql.ErrNoRows → ถือเป็นเรื่องปกติ แค่ return not found ไม่ต้อง log
connection refused → infrastructure issue → log ที่นี่ครั้งเดียว

แก้ที่ Handler — log เฉพาะที่ไม่คาดคิด

Handler ควรตอบกลับ client — ไม่ต้อง log ทุก error⁴:

func (h *UserHandler) GetUser(w http.ResponseWriter, r *http.Request) {
    id := chi.URLParam(r, "id")
    user, err := h.svc.GetUser(r.Context(), id)
    if err != nil {
        // Service จัดการไปแล้ว — handler ก็แค่ map error → HTTP status
        switch {
        case strings.Contains(err.Error(), "not found"):
            http.Error(w, "not found", http.StatusNotFound)
        default:
            slog.Error("unhandled error", "path", r.URL.Path, "error", err)
            http.Error(w, "internal error", http.StatusInternalServerError)
        }
        return
    }
    json.NewEncoder(w).Encode(user)
}

Log หลังแก้:

2026/06/29 17:05:00 ERROR database error user_id=42 error="FindByID: connection refused"

หนึ่งบรรทัด — หนึ่ง error — ครบ context 🎉

สรุปหลักการ

ระดับ	บทบาท	Log?
Repository	Data access — return error	❌
Service	Business logic — ตัดสินใจว่า error คืออะไร	✅ ครั้งเดียว
Handler	HTTP — map error เป็น status code	❌ (ยกเว้น unexpected)

The Golden Rule

// ✅ ถูก
if err != nil {
    return fmt.Errorf("doThing: %w", err) // return — ให้ caller จัดการ
}

// ✅ ถูก (เมื่อเราจัดการแล้วจริง ๆ)
if err != nil {
    log.Printf("background task failed: %v", err) // log — ไม่ return
    return  // จบที่นี่
}

// ❌ ผิด — อย่าทำเด็ดขาด
if err != nil {
    log.Printf("error: %v", err)  // log แล้ว...
    return err                     // return อีก = double report
}

เพิ่มเติม — Structured Logging แบบ Go 1.21+

Go 1.21 เพิ่ม log/slog เข้ามาใน stdlib⁵ — ใช้ structured logging แทน log.Printf:

slog.Error("database error",
    slog.String("user_id", id),
    slog.Any("error", err),
)

ข้อดี: log เป็น JSON, filter ด้วย field ได้, ต่อกับ observability tools (Loki, Datadog, Grafana) ง่าย

เชิงอรรถ — Go Naming Philosophy

บทความนี้ตั้งใจใช้ชื่อ function แบบเดียวกับที่ standard library และ community Go ใช้:

FindByID — prefix verb (Find) + preposition (By) + noun (ID) — บอกว่า หา ด้วย อะไร
GetUser — prefix verb (Get) + noun (User) — บอกว่า เอาอะไร
ชื่อแบบนี้มีที่มาจาก Effective Go — "the name of a method should say what it does"

Function สั้น ตรงประเด็น อ่านแล้วรู้ว่าทำอะไร — โดยไม่ต้องมีคำว่า Do, Handle, Process มาต่อข้างหน้าโดยไม่จำเป็น

สรุป

Double Report เกิดจากความไม่แน่ใจมากกว่าความผิดพลาด — พอเข้าใจ Go error handling philosophy แล้วจะเห็นว่ามันสวย:

Repository — just return
Service — ตัดสินใจว่า error คืออะไร แล้ว log ครั้งเดียว
Handler — map error → HTTP status

แค่นี้ log ก็สะอาด อ่านรู้เรื่อง ดีบั๊กง่าย 🧹

"Error คือ value" — หนึ่งใน Go proverbs โดย Rob Pike: error ไม่ใช่ exception ที่ต้อง throw/catch — มันคือค่า return ธรรมดาที่ caller ตรวจสอบด้วย if err != nil { ... } ↩
"Either log or return" — Dave Cheney, ผู้เขียนบทความคลาสสิคเรื่อง Go error handling: "Don't just check errors, handle them gracefully" — https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully ↩
Error wrapping: fmt.Errorf("context: %w", err) ใช้ %w verb เพื่อ wrap error โดยไม่เสีย error chain — errors.Is() และ errors.As() จะ traverse ผ่าน wrapped errors ได้ ↩
Handler logging: ถ้าใช้ HTTP middleware (เช่น chi, echo, gin) — หลายตัวมี request logger ในตัวอยู่แล้ว ไม่ต้อง log ซ้ำใน handler ↩
log/slog: structured logging ใน Go 1.21+ — ใช้ key=value pairs แทน format string — ทำให้ log parse ด้วยเครื่องมือ automation ได้ https://go.dev/blog/slog ↩

Go 1.27 — Generic Methods, JSON v2, UUID ใน stdlib ฯลฯ

Gophernment Co — Mon, 29 Jun 2026 10:23:12 +0000

Go 1.27 — Generic Methods, JSON v2, UUID ใน stdlib ฯลฯ

⚠️ Go 1.27 ยังไม่ release นะทุกคน release notes ยังเป็น draft อยู่ คาดว่าจะออกจริงประมาณ สิงหาคม 2026
เราไปดูกันดีกว่าว่ารอบนี้มีอะไรน่าตื่นเต้นบ้าง

ส่วนตัวผมตื่นเต้นกับเวอร์ชันนี้มาก เพราะมีของที่รอมานานหลายอย่างโผล่มาใน draft นี้พร้อมกัน ทั้ง Generic Methods ที่คนเรียกร้องกันมาตั้งแต่ Go 1.18, JSON v2 ที่คุยกันมาเป็นปี ๆ, และ UUID ใน stdlib ที่หลายคน (รวมผม) รอมานานจนเกือบลืม

งั้นมาเริ่มกันเลย

🎯 Generic Methods — ของที่รอมา 4 ปี

เล่าเรื่องก่อน

ย้อนกลับไปตอน Go 1.18 (ปี 2022) — Go เพิ่งใส่ generics เข้ามาครั้งแรก¹ ตอนนั้น community ดีใจกันใหญ่ แต่ก็มีเสียงบ่นปนมาด้วยว่า "เฮ้ย แล้ว generic methods ล่ะ?"

ปัญหามันเป็นแบบนี้...

สมมติเราเขียน Set[T] ขึ้นมาตัวนึง:

type Set[T comparable] struct {
    m map[T]struct{}
}

แล้วเราอยากมี method Map — แปลงจาก Set[int] เป็น Set[string] — ใน Go 1.18-1.26 เราทำแบบนี้ไม่ได้:

// ❌ ทำไม่ได้ใน Go ≤ 1.26 — method ห้ามมี type parameter ตัวเอง
func (s *Set[T]) Map[U any](f func(T) U) *Set[U] {
    // compiler จะด่า "method must have no type parameters"
}

ทำไม? เพราะตอน Go 1.18 ทีมออกแบบเลือกที่จะ implement แค่ "generic functions" ในระดับ package ก่อน — method ยังต้องเหมือนเดิม² การจะทำให้ method มี type parameter ของตัวเองได้ มันต้องแก้ compiler, runtime, และ reflect ใหม่ยกใหญ่

จนมาถึง Go 1.27

ในที่สุด — method มี type parameter ของตัวเองได้แล้ว!

// ✅ Go 1.27 — ได้แล้วครับ!
func (s *Set[T]) Map[U any](f func(T) U) *Set[U] {
    result := &Set[U]{m: make(map[U]struct{})}
    for v := range s.m {
        result.m[f(v)] = struct{}{}
    }
    return result
}

จะเกิดอะไรขึ้น? เรา chain method สวย ๆ ได้เลย:

scores := NewSet(10, 20, 30)

// แปลงเป็น string → filter → นับ — ในบรรทัดเดียว!
labels := scores.
    Map(func(n int) string { return fmt.Sprintf("score_%d", n) }).
    Filter(func(s string) bool { return len(s) > 7 })

ก่อน Go 1.27: ต้องเขียนแบบนี้ — function กระจายอยู่ใน package เปล่า ๆ อ่านไม่รู้เรื่อง:

labels := FilterSet(MapSet(scores, func(n int) string { ... }),
    func(s string) bool { ... })

ข้อจำกัดที่ยังมีอยู่: interface method ยังมี type parameter ไม่ได้ และ generic method ก็ implement interface ไม่ได้³

ทำไมถึงสำคัญ?

ลองนึกภาพเวลาคุณเขียน library ที่ return type เป็น generic container — Set[T], Result[T], Option[T] — คุณอยากให้คนใช้ chain operation ต่อได้ใช่ไหม? Generic methods ทำให้สิ่งนี้เป็นจริง

💡 Footnote: ทีม Go ใช้เวลานานกับฟีเจอร์นี้เพราะ philosophy ของ Go คือ "เรียบง่ายก่อน ถูกต้องเสมอ" การเพิ่ม generic methods ต้องทำให้แน่ใจว่ามันไม่ทำให้ type inference ช้าลง ไม่มี edge case แปลก ๆ และการคอมไพล์ยังเร็วเหมือนเดิม

📦 JSON v2 — encoding/json ภาคใหม่

ทำไมต้อง v2?

encoding/json ปัจจุบันอยู่กับเรามาตั้งแต่ Go 1.0 (ปี 2012) มันทำงานได้ดี แต่ปัญหาสะสมมาตลอด 13 ปี:

Performance — ใช้ reflection เยอะ⁴ marshal/unmarshal struct ที่มี nested field เยอะ ๆ แล้วช้า
API ไม่ยืดหยุ่น — อยาก customise marshaling? ต้อง implement json.Marshaler เองทั้งก้อน ไม่ใช่แค่บาง field
Streaming ไม่สะดวก — ถ้าข้อมูล JSON มาเป็น streaming (เช่น WebSocket, Server-Sent Events) การ decode ด้วย json.Decoder ตอนนี้ยังมีข้อจำกัดหลายอย่าง
Error messages — ถ้า json ไม่ตรง schema error message อ่านยาก — "unexpected token" แล้วจบ ไม่บอกว่าบรรทัดไหน field ไหน

มีอะไรใน v2

Go 1.27 เอา encoding/json/v2 เข้ามาใน stdlib — ยังเป็น experimental แต่มันคือรากฐานของ JSON handling ยุคใหม่

encoding/json/v2 — API ใหม่ที่ยืดหยุ่นกว่า, เร็วกว่า
encoding/json/jsontext — low-level tokenizer/encoder สำหรับคนที่อยากทำอะไร custom กับ JSON stream โดยตรง

รายละเอียดยังไม่เปิดเผยหมด เพราะ v2 ยังอยู่ระหว่างพัฒนา แต่ที่แน่ ๆ คือมันจะแก้ pain point ทั้ง 4 ข้อข้างบน

💡 สำหรับ junior dev: ถ้าตอนนี้คุณใช้ encoding/json อยู่ — ใช้ต่อไปได้เลย ไม่ต้องรีบเปลี่ยน v2 ยังเป็น experimental และ API อาจเปลี่ยนได้ระหว่างทาง

🆔 UUID ใน stdlib — ในที่สุด!

มันคืออะไร?

UUID (Universally Unique Identifier) คือ ID ที่สร้างแล้ว "ไม่ซ้ำ" กับใครในโลก — ใช้แทน auto-increment ID เวลาอยากให้ ID เดาจากภายนอกไม่ได้⁵

ก่อน Go 1.27 — คุณต้อง go get github.com/google/uuid (ดาวน์โหลด ~1.3M) หรือ gofrs/uuid — ซึ่งก็ดีนะ แต่คำถามคือ "ทำไมของพื้นฐานขนาดนี้ถึงไม่อยู่ใน stdlib?"

ใน Go 1.27

import "uuid"

// UUID v7 — timestamp-based, sort ได้ตามเวลา
id := uuid.NewV7()
fmt.Println(id.String())
// Output: 019309e2-29a3-7b2f-a4d5-80d44c4b3f1d

ทำไมต้อง UUID v7? UUID ธรรมดา (v4) ใช้ random ล้วน ๆ — ทำให้ index ใน database B-tree⁶ กระจัดกระจาย UUID v7 เอา timestamp ใส่ไว้ข้างหน้า ทำให้ "sort ได้ตามเวลา" — ข้อนี้สำคัญมากสำหรับ performance database

เปรียบเทียบง่าย ๆ: UUID v4 = จับสลากแบบสุ่ม / UUID v7 = จับสลากแบบเรียงตามคิว

🧪 SIMD ใน Go — CPU มัลติทาสกิ้ง

SIMD คืออะไร?

สมมติคุณมีตัวเลข 8 ตัว แล้วอยากบวก 1 ให้ทุกตัว — ปกติ CPU ทำทีละตัว 8 รอบ

SIMD (Single Instruction, Multiple Data) คือการทำ "คำสั่งเดียว" กับ "ข้อมูลหลายตัวพร้อมกัน" — เหมือนเชฟที่หั่นผักทีเดียว 8 หัวแทนที่จะหั่นทีละหัว

// Concept (ยังไม่ใช่ syntax จริง)
// ปกติ: for i := range data { data[i] += 1 }  ← 8 รอบ
// SIMD:  data += [1,1,1,1,1,1,1,1]            ← รอบเดียว!

Go 1.27 มี simd + simd/archsimd เป็น experimental package — ยังต้อง build ด้วย GOEXPERIMENT=simd

ใช้กับอะไรได้บ้าง:

Image processing (ปรับแสง, resize พร้อมกันหลาย pixel)
Machine learning inference
Cryptography (เข้ารหัสหลาย block พร้อมกัน)
Audio/Video encoding

💡 ต้องบอกว่า SIMD ใน Go ยังเด็กมาก — อย่าเพิ่งเอาไปใช้ production แต่มันเป็นการวางรากฐานที่สำคัญมาก

⚡ Runtime Improvements

Goroutine Leak Profile

goroutine⁷ รั่วคือฝันร้ายของ Go dev — มันใช้ memory ไปเรื่อย ๆ โดยไม่รู้ตัว

Go 1.27 เพิ่ม goroutine leak profile — ใช้กับ go tool pprof เพื่อดูว่า goroutine ตัวไหนที่เกิดแล้วไม่ยอมตาย

# ดู goroutine leak profile (คาดว่าใช้ประมาณนี้)
go tool pprof http://localhost:6060/debug/pprof/goroutine

Faster Memory Allocation

รายละเอียดยังไม่เปิดเผยมาก แต่ทีม runtime บอกว่าปรับปรุง allocator ให้เร็วขึ้น — โดยเฉพาะเคส allocate ของเล็ก ๆ จำนวนมาก

🖥️ Ports

macOS (Darwin) — รองรับเวอร์ชันล่าสุด
PowerPC 64-bit (ppc64) — กลับมาอยู่ใน first-class port⁸ ใครใช้ IBM Power server ยิ้มได้

📊 สรุปให้

หมวด	ฟีเจอร์	น่าตื่นเต้น?	ใช้ production ได้เลย?
Language	Generic Methods	🔥🔥🔥	✅ (หลังออกจริง)
Language	Struct Literal Keys	✨	✅
Language	Function Type Inference	✨	✅
stdlib	`encoding/json/v2`	🔥🔥	🧪 experimental
stdlib	`uuid`	🔥	✅
stdlib	`crypto/mldsa`	🔥	✅
stdlib	`simd`	🔥🔥	🧪 experimental
Runtime	Faster Allocation	✨	✅
Runtime	Goroutine Leak Profile	✨	✅

Go 1.27 ยังอีกประมาณ 2 เดือนกว่าจะออกจริง — release notes อาจเปลี่ยนได้ ติดตามที่ go.dev/doc/go1.27

📚 Footnotes — อ่านเพิ่มเติมสำหรับคนอยากรู้ลึก

📚 Source: Go 1.27 Release Notes (Draft) — The Go Programming Language

Go Generics (1.18): Go ใส่ type parameter เข้ามาในปี 2022 — ใช้ syntax func F[T any](t T) และ constraint แบบ [T interface{ ~int | ~float64 }] — ทำให้เขียน function ที่ทำงานกับหลาย type ได้โดยไม่ต้องใช้ interface{} + type assertion ↩
ทำไม generic methods ถึงยาก: เพราะ Go method ทำงานผ่าน "method set" ซึ่งถูกกำหนดที่ compile time การเพิ่ม type parameter ให้ method ทำให้ method set กลายเป็น "generic" — ต้องแก้ทั้ง compiler (SSA generation), runtime (interface dispatch), และ reflect ↩
Interface กับ generic method: ใจความคือ interface เป็น "สัญญา" ที่ concrete type ต้อง implement — ถ้า method มี type parameter มันก็เหมือน "สัญญาที่ยังไม่ได้ระบุประเภท" เลย implement interface ไม่ได้ ↩
Reflection: encoding/json ใช้ reflect เพื่ออ่าน struct tags (json:"name") และ type ของ field — การใช้ reflect มี overhead เพราะต้อง resolve type ที่ runtime แทนที่จะทำตอน compile time ↩
UUID vs Auto-Increment: Auto-increment ID (1, 2, 3, ...) ทำให้คนนอกเดาได้ว่ามี record กี่อัน และเดา ID ของ record ถัดไปได้ UUID แก้ปัญหานี้ ↩
B-tree Index: index มาตรฐานใน database (PostgreSQL, MySQL) — ทำงานเร็วเมื่อข้อมูล "เรียงตามลำดับ" UUID v4 สุ่ม ทำให้ B-tree ต้องจัดเรียงบ่อย UUID v7 เรียงตามเวลา ทำให้ insert แล้ว index เป็นระเบียบ — performance ดีกว่า ↩
Goroutine: lightweight thread ของ Go — สร้างได้เป็นแสน ๆ ตัวโดยใช้ memory น้อย แต่ถ้า goroutine เกิดแล้วไม่มีทางจบ (leak) มันจะกิน memory สะสมไปเรื่อย ๆ ↩
First-class port: หมายถึง architecture ที่ได้รับการทดสอบแบบเต็มรูปแบบ CI/CD — มี binary prebuilt ให้บน go.dev/dl — ไม่ใช่แค่ "cross-compile ได้" ↩

DEV Community: Gophernment Co

เขียน Go แบบ Java/Ruby/PHP — ทางลัดสู่ Technical Debt โดยไม่รู้ตัว

เขียน Go แบบ Java/Ruby/PHP — ทางลัดสู่ Technical Debt โดยไม่รู้ตัว

ปัญหาไม่ได้อยู่ที่ภาษา — อยู่ที่ "สำเนียง"

☕ Java → Go: OOP Overdose

Interface ทุกอย่าง — "เผื่อไว้"

Getter/Setter ทุก field — "เผื่อมี logic ภายหลัง"

"Architecture" ก่อนเขียนโค้ด

💎 Ruby → Go: Magic มากเกิน

method_missing ใน Go — ไม่มีวันได้

nil ≠ nil — หลุมพรางที่ Ruby dev มองข้าม

🐘 PHP → Go: Frameworks First

ทุกอย่างต้องมี framework

Global state

🐍 Python → Go: Exception Mindset

Error คือ Exception

Decorator ซ้อน Decorator

สรุป — เรียนรู้ Grammar ไม่พ้อง ต้องเรียนรู้ "สำเนียง"

วิธีแก้ — อ่าน Effective Go

เชิงอรรถ

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

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

ปัญหาหน้าตาเป็นยังไง

ทำไมเราถึงเผลอทำ

วิธีที่ถูกต้อง — Log หรือ Return อย่างใดอย่างหนึ่ง

แก้ที่ Repository — return เฉย ๆ, ไม่ต้อง log

แก้ที่ Service — business logic ตรงนี้

แก้ที่ Handler — log เฉพาะที่ไม่คาดคิด

สรุปหลักการ

The Golden Rule

เพิ่มเติม — Structured Logging แบบ Go 1.21+

เชิงอรรถ — Go Naming Philosophy

สรุป

Go 1.27 — Generic Methods, JSON v2, UUID ใน stdlib ฯลฯ

Go 1.27 — Generic Methods, JSON v2, UUID ใน stdlib ฯลฯ

🎯 Generic Methods — ของที่รอมา 4 ปี

เล่าเรื่องก่อน

จนมาถึง Go 1.27

ทำไมถึงสำคัญ?

📦 JSON v2 — encoding/json ภาคใหม่

ทำไมต้อง v2?

มีอะไรใน v2

🆔 UUID ใน stdlib — ในที่สุด!

มันคืออะไร?

ใน Go 1.27

🧪 SIMD ใน Go — CPU มัลติทาสกิ้ง

SIMD คืออะไร?

⚡ Runtime Improvements

Goroutine Leak Profile

Faster Memory Allocation

🖥️ Ports

📊 สรุปให้

📚 Footnotes — อ่านเพิ่มเติมสำหรับคนอยากรู้ลึก

`method_missing` ใน Go — ไม่มีวันได้

`nil` ≠ `nil` — หลุมพรางที่ Ruby dev มองข้าม