ถ้า AI เขียนโค้ดได้ แล้วทำไมยังต้องใช้ Python?

 (medium.com/@NMitchem)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อมีการพัฒนาซอฟต์แวร์แบบมี AI ช่วย เกณฑ์การเลือกภาษาก็เปลี่ยนจาก ความเร็วที่มนุษย์เขียนได้ ไปเป็น ความสามารถของ AI ในการแก้ไขโค้ด และประสิทธิภาพขณะรัน
  • ในปี 2026 Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 ทำคะแนน SWE-bench Verified 80% ได้สำเร็จ
  • Rust มี วงจรป้อนกลับจากคอมไพเลอร์ ที่ช่วยให้ AI แก้ไขตัวเองได้ดีขึ้น และ Go กับ Swift ก็เหมาะกับเอเจนต์เช่นกันเพราะตรวจชนิดข้อมูลได้รวดเร็ว
  • การย้ายระบบครั้งใหญ่เกิดขึ้นจริงแล้ว เช่น การพอร์ตคอมไพเลอร์ TypeScript ไปเป็น Go, คอมไพเลอร์ภาษา C ที่เขียนด้วย Rust, Rue, และการพอร์ต JavaScript engine ของ Ladybird
  • แม้ ecosystem ของ Python·JavaScript จะพึ่งพาเครื่องมือและ wrapper ที่สร้างด้วย Rust มากขึ้น แต่ก็ยังมีข้อยกเว้นอย่าง Prisma, PyTorch และภาษาขนาดเล็กบางภาษา

เกณฑ์การเลือกภาษาที่เปลี่ยนไปเพราะการพัฒนาแบบมี AI ช่วย

  • ตัวเลือกตั้งต้นของโปรเจกต์ใหม่มาอย่างยาวนานคือ Python หรือ TypeScript
    • เพราะมี ecosystem ใหญ่ มีตลาดแรงงานกว้าง และทำเดโมได้รวดเร็ว
    • แม้ Rust, Go, C++ จะให้ประสิทธิภาพสูงกว่า 10–100 เท่า แต่ระยะเวลาเรียนรู้ ตลาดคนทำงานที่เล็กกว่า และระบบ build ที่ยุ่งยากกว่ากลับกลายเป็นต้นทุน
    • จึงมักออกเวอร์ชัน Python ไปก่อนแล้วค่อยบอกว่า “ไว้ค่อยปรับปรุงประสิทธิภาพทีหลัง” แต่ในความจริงก็มักคงสภาพเดิมไว้
  • เมื่อ AI เริ่มจัดการภาษาที่ยากได้ ข้อตกลงนี้ก็เริ่มสั่นคลอน
    • ในการเลือกภาษา น้ำหนักจึงขยับจาก “มนุษย์เขียนได้เร็วไหม” ไปสู่ “AI เขียนและแก้ได้ดีไหม” และประสิทธิภาพขณะรันมากขึ้น

ภาษาที่ยากกลับกลายเป็นเรื่องง่ายสำหรับ AI ก่อน

  • เมื่อ 2 ปีก่อน GPT-4 ยังอยู่ในระดับที่แต่งชื่อ crate ที่ไม่มีอยู่จริงระหว่างเขียนฟังก์ชัน Rust
  • แต่ในเดือนเมษายน 2026 Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 ต่างก็ทำคะแนนเกิน 80% บน SWE-bench Verified ในช่วงเวลาห่างกันเพียงไม่กี่สัปดาห์
  • ห้องวิจัยต่าง ๆ กำลังปรับแต่งให้เหมาะกับงานระบบโดยตรง
    • บั๊กจาก concurrency
    • race condition
    • ข้อบกพร่องเชิงสถาปัตยกรรมที่พบได้ตั้งแต่ช่วงวางแผน
  • CtrlAltDwayne มองว่าเหตุผลที่ Rust แข็งแกร่งในปี 2026 ไม่ได้อยู่ที่ memory safety หรือประสิทธิภาพ แต่คือ วงจรป้อนกลับจากคอมไพเลอร์
    • AI เขียน Rust ได้ดีกว่า C++
    • ข้อความ error จากคอมไพเลอร์ของ Rust กลายเป็นสัญญาณที่ช่วยให้โมเดลแก้ไขตัวเองแบบเรียลไทม์
    • Rust ทำงานราวกับเป็นภาษาที่ “ถูกออกแบบมาโดยบังเอิญล่วงหน้า 10 ปี” ให้เหมาะกับการพัฒนาแบบมี AI ช่วย
  • ตรรกะเดียวกันนี้ใช้ได้กับ Go และ Swift ด้วย แม้ระดับจะต่างกัน
    • ระบบชนิดข้อมูลที่เข้มแข็งและวงจร compile/ตรวจสอบที่รวดเร็ว ทำให้เอเจนต์ได้ลูปการทำซ้ำที่ถี่
    • ภาษาระดับระบบที่เคยยากสำหรับมนุษย์ อาจกลับกลายเป็นเป้าหมายที่ง่ายกว่าสำหรับเอเจนต์

กรณีที่เกิดขึ้นจริงแล้ว

  • Microsoft พอร์ตคอมไพเลอร์ TypeScript ไปเป็น Go

    • Microsoft เปิดตัว TypeScript 7.0 beta พร้อมพอร์ต codebase TypeScript ที่มีอายุ 10 ปีไปเป็น Go
    • TypeScript 7.0 beta เร็วกว่า 6.0 ราว 10 เท่า
    • ตาม การตัดสินใจของ Anders Hejlsberg Go ให้ประโยชน์ด้านประสิทธิภาพส่วนใหญ่ได้ด้วยต้นทุนทางวิศวกรรมเพียงบางส่วน
    • นี่สะท้อนว่าการคำนวณความคุ้มค่าระหว่างความพยายามกับผลลัพธ์ได้เปลี่ยนไปมาก จนหนึ่งในองค์กร JS/TS ที่ใหญ่ที่สุดยอมเลือกภาษาที่เร็วกว่าและยากกว่าให้กับเครื่องมือหลักของตน

  • คอมไพเลอร์ C ที่เขียนด้วย Rust โดยใช้เอเจนต์ Claude 16 ตัว

    • Nicholas Carlini นักวิจัยจาก Anthropic ประสานงาน Claude 16 เอเจนต์แบบขนาน เพื่อเขียน คอมไพเลอร์ภาษา C สำหรับ production ด้วย Rust
    • ขนาดงานอยู่ที่ 100,000 บรรทัด และสามารถบูต Linux 6.9 บน x86·ARM·RISC-V ได้
    • มันคอมไพล์ QEMU, FFmpeg, SQLite, PostgreSQL, Redis และยังรัน Doom ได้
    • ต้นทุนรวมอยู่ที่ต่ำกว่า 20,000 ดอลลาร์ ตลอดเกือบ 2,000 เซสชันของ Claude Code
    • คอมไพเลอร์ C ที่เขียนด้วย Rust เคยเป็นงานระดับวิทยานิพนธ์บัณฑิตศึกษา แต่ตอนนี้ไม่ได้เป็นงานที่พบได้ยากอีกต่อไป

  • Rue ของ Steve Klabnik

    • Steve Klabnik ผู้ร่วมเขียน The Rust Programming Language และผู้มีประสบการณ์ Rust 13 ปี สร้าง ภาษา systems ใหม่ชื่อ Rue ร่วมกับ Claude ภายใน 2 สัปดาห์
    • ผลลัพธ์มีขนาดราว 70,000 บรรทัดของ Rust
    • เขาระบุว่างาน 2 สัปดาห์ครั้งนี้ไปได้ไกลกว่าความพยายามก่อนหน้าที่เคยใช้เวลาหนึ่งถึงสองเดือน

  • การพอร์ต JavaScript engine ของ Ladybird ไปเป็น Rust

    • Andreas Kling ผู้ก่อตั้งเบราว์เซอร์ Ladybird และวิศวกร C++ ใช้ Claude Code และ Codex พร้อม prompt ย่อยหลายร้อยรายการ เพื่อ พอร์ต JavaScript engine ของ Ladybird จาก C++ ไปเป็น Rust ภายใน 2 สัปดาห์
    • ผลลัพธ์มีขนาดราว 25,000 บรรทัดของ Rust และได้ความเทียบเท่าระดับไบต์กับต้นฉบับ C++
    • เมื่อรวม test262 และชุดทดสอบของ Ladybird แล้ว ไม่พบ regression ในการทดสอบกว่า 65,000 รายการ
    • เขาระบุว่าถ้าทำด้วยมือ งานเดียวกันนี้น่าจะใช้เวลาหลายเดือน

ตรรกะเรื่อง “ecosystem” ที่เริ่มอ่อนแรงลง

  • จุดแข็งที่สุดของ Python และ JavaScript ไม่ใช่ตัวภาษาเอง แต่คือ ecosystem
    • มีฐานอย่าง FastAPI, Django, PyTorch, React, Next.js และแพ็กเกจใน npm กว่า 4 ล้านรายการ
    • ที่ทีมสามารถปล่อยฟีเจอร์ได้ภายในไม่กี่วัน ก็เพราะ ecosystem แก้ปัญหาไว้แล้ว 90%
  • ข้อได้เปรียบนี้เคยเป็นปัจจัยชี้ขาดตลอด 10 ปีที่ผ่านมา แต่ในช่วง 2 ปีหลังเริ่มอ่อนแรงลง
  • ภายใน ecosystem ของ Python เองก็พึ่งพา องค์ประกอบที่สร้างด้วย Rust มากขึ้นเรื่อย ๆ
    • validation core ทั้งหมดของ pydantic เป็นไลบรารี Rust
    • Polars ซึ่งเป็นทางเลือกของ pandas เขียนด้วย Rust
    • tokenizers ของ Hugging Face และ orjson ก็เป็น Rust เช่นกัน
    • ตาม JetBrains 2025 Python survey การใช้ Rust ในส่วนขยายไบนารีของ Python เพิ่มจาก 27% เป็น 33% ภายในปีเดียว
  • พื้นฐานของเครื่องมือพัฒนาก็เคลื่อนไปในทิศทางเดียวกัน
    • Astral ที่ Charlie Marsh ก่อตั้งในปี 2022 เปิดตัว ruff, uv, ty ซึ่งเขียนด้วย Rust และยอดดาวน์โหลดรายเดือนของทั้งสามเครื่องมือเติบโตจาก 0 ไปสู่หลักหลายร้อยล้านครั้ง
    • เมื่อวันที่ 19 มีนาคม 2026 OpenAI เข้าซื้อ Astral และประเมินว่า uv ช่วยประหยัดเวลา compute ของ Codex ได้ราว 1 ล้านนาทีต่อสัปดาห์
    • เมื่อ 10 สัปดาห์ก่อน Anthropic ก็เข้าซื้อ Bun
    • Bun มียอดดาวน์โหลดรายเดือน 7 ล้านครั้ง และ GitHub star 89,000 พร้อมถูกเรียกว่าเป็น “โครงสร้างพื้นฐานจำเป็นของวิศวกรรมซอฟต์แวร์ที่ขับเคลื่อนด้วย AI”
    • VoidZero ของ Evan You เปิดตัว Rolldown-Vite
    • Rust bundler ตัวนี้ลดเวลา build 2.5 นาทีของ GitLab ลงเหลือ 40 วินาที และลดการใช้หน่วยความจำลงเหลือ 1/100
  • Lee Robinson รองประธานฝ่ายผลิตภัณฑ์ของ Vercel กล่าวว่า “เราไปถึงเพดานของการ optimize ใน JS แล้ว”
  • แพ็กเกจที่นำมาใช้จาก Python และ JavaScript กำลังกลายเป็น wrapper ของโค้ดที่เขียนด้วยภาษาซึ่งเดิมมองว่ายากเกินกว่าจะส่งมอบได้โดยตรงมากขึ้นเรื่อย ๆ
    • และเมื่อวันนี้สามารถส่งมอบด้วยภาษาเหล่านั้นได้โดยตรง wrapper ก็เริ่มดูเหมือน overhead

การเปลี่ยนจากการ patch ไปสู่การ port ที่ง่ายกว่า

  • วงจรเชิงบวกของ ecosystem โอเพนซอร์สเดิมยึดกับ การ patch เป็นศูนย์กลาง
    • เลือก Python เพราะมันง่าย
    • พบ bug ใน dependency
    • แก้ไขแล้วส่งกลับ upstream
    • ecosystem ก็แข็งแรงขึ้น
  • แต่เอเจนต์กำลังย้ายหน่วยของการมีส่วนร่วมจาก patch ไปเป็น การ port
  • Armin Ronacher ผู้สร้าง Flask ใช้เอเจนต์ในเดือนมกราคมเพื่อ พอร์ตไลบรารี Rust ชื่อ MiniJinja ไปเป็น Go
    • เวลารวมทั้งหมดคือ 10 ชั่วโมง
    • ในจำนวนนั้น 3 ชั่วโมงเป็นการกำกับดูแล และอีก 7 ชั่วโมงทำงานแบบไร้คนเฝ้า
    • เวลาที่มนุษย์ใช้จริงมีเพียง 45 นาที
    • ค่าใช้จ่ายด้าน API อยู่ที่ 60 ดอลลาร์
  • ถ้าการพอร์ตไลบรารีข้ามภาษาเป็นงาน 45 นาที ตรรกะของการส่งแก้ไขเข้าไลบรารีของคนอื่นก็อ่อนแรงลง
    • ไม่ใช่ “patch ได้ แล้วทำไมไม่ fork” อีกต่อไป แต่กลายเป็น “fork ได้ แล้วทำไมต้อง patch”
  • Armin Ronacher มองว่ามูลค่ากำลังย้ายจากตัวโค้ดไปสู่ ชุดทดสอบและเอกสาร
    • ชุดทดสอบที่ดีอาจมีค่ามากกว่าตัวโค้ดเอง
  • วงจรที่สร้าง PyPI และ npm ยังทำงานอยู่ตอนนี้ แต่ยังไม่ชัดว่ามันจะทำงานเหมือนเดิมในปี 2028 หรือไม่

ข้อยกเว้นที่ยังคงอยู่

  • ไม่ใช่ว่าการเปลี่ยนแปลงทั้งหมดไหลไปในทิศทางเดียว
  • ในบางกรณี ตัวเลือกเดิมก็ยังถูกต้อง
    • Prisma ถอด Rust query engine ออก แล้วเปลี่ยนไปใช้แกน TypeScript/WASM
    • ขนาด bundle ลดลง 85%
    • query เร็วขึ้นสูงสุด 3.4 เท่า
    • ไบนารี Rust แบบเนทีฟไม่เหมาะกับรันไทม์แบบ serverless
  • PyTorch ยังครองงานวิจัย deep learning ราว 85%
    • ตำแหน่งนี้ไม่เปลี่ยนง่าย เพราะน้ำหนักของโมเดลไม่ได้ขึ้นกับว่าห่อหุ้มด้วยภาษาอะไร
  • AI ก็ไม่ได้รับมือกับทุกภาษาระบบได้ดีเท่ากัน
    • ภาษาขนาดเล็กกว่าอย่าง Zig, Haskell, Gleam ยังมีคุณภาพงานที่ AI สร้างได้ไม่เท่ากับ Rust หรือ Go ในตอนนี้
    • ข้อมูลฝึกเป็นตัวกำหนดขอบเขตที่โมเดลจะช่วยได้
    • Rust กับ Go มีโค้ดบน GitHub มากพอจึงได้เปรียบ
    • ส่วน Zig, Haskell, Gleam ยังอยู่ในฝั่งที่เสียเปรียบของเส้นโค้งนี้

ทำไมการเปลี่ยนแปลงนี้อาจยั่งยืน

  • ตรรกะป้องกันเดิมของ Python และ TypeScript แท้จริงแล้วคือการป้องกันเรื่อง ประสบการณ์นักพัฒนา
    • คนเลือกมันเพราะช่วยลดแรงเสียดทานระหว่างไอเดียของมนุษย์กับผลิตภัณฑ์ที่ปล่อยใช้งานได้จริง
    • Rust ไม่ใช่ภาษาที่ช้าในตอนรัน แต่เป็นภาษาที่ช้าเมื่อต้องปล่อยของตอนตีสอง
  • ตอนนี้เอเจนต์เริ่มรับช่วงส่วนที่ยากไปทำ
    • บทบาทของมนุษย์จึงย้ายจาก “การเขียนโค้ด” ไปเป็น “การออกแบบระบบและทบทวนผลลัพธ์”
    • ในกระแสนี้ ความสะดวกทางไวยากรณ์ของ Python จึงสำคัญน้อยลงในแต่ละสาขาแตกย่อย
    • ส่วนข้อได้เปรียบด้าน runtime ของภาษาที่ยากกว่าจะสะสมทุกวันเมื่อบริการรันอยู่ใน production
  • ในบทความเดือนกุมภาพันธ์ A Language For Agents Armin Ronacher มองว่าต้นทุนการเขียนโค้ดลดลงอย่างรวดเร็ว ทำให้ความกว้างของ ecosystem สำคัญน้อยลง
  • ตลอด 20 ปีที่ผ่านมา การเลือกภาษาถูกกำหนดโดยข้อจำกัดที่ว่า “มนุษย์เป็นคนเขียนโค้ด และมนุษย์ช้าเมื่ออยู่กับภาษาระดับล่าง”
    • แต่ข้อจำกัดนี้กำลังเริ่มหายไป
  • ในแบบสำรวจ Stack Overflow ปี 2025 Rust เป็นภาษาที่ได้รับความชื่นชอบมากที่สุดติดต่อกันเป็นปีที่ 10 ที่ 72%
    • Gleam ได้ 70%
    • Elixir ได้ 66%
    • Zig ได้ 64%
    • ความชอบมีอยู่ก่อนแล้ว และตอนนี้เครื่องมือกำลังไล่ตามความชอบนั้นทัน

ก้าวถัดไปสู่ภาษาที่ง่ายสำหรับเอเจนต์

  • Karpathy กล่าวไว้ใน เดือนกุมภาพันธ์ ว่า LLM กำลังเปลี่ยนภูมิทัศน์ของข้อจำกัดในซอฟต์แวร์ทั้งหมด
    • เขามองว่ากระแสการพอร์ตจาก C ไป Rust คือสัญญาณของเรื่องนี้
    • และยังเสริมว่าแม้แต่ Rust เองก็อาจยังไม่ใช่ภาษาที่เหมาะที่สุดสำหรับ LLM
  • ผู้ชนะในตอนนี้อาจเป็นเพียงจุดเริ่มต้น และรูปแบบสุดท้ายอาจไปได้ไกลกว่านี้
  • @RealRichomie กล่าวเมื่อ 24 เมษายน ว่าอนาคตของการเขียนโปรแกรมจะไปสู่ภาษา ที่ง่ายที่สุดสำหรับเอเจนต์ ไม่ใช่ภาษาที่ง่ายที่สุดสำหรับมนุษย์
    • วิศวกรสามารถปล่อยแอป Mac ได้ทั้งที่เดิมไม่รู้จัก Rust หรือ Tauri เลย
    • ผลลัพธ์มีขนาดเพียงราว 1/10 ของเวอร์ชัน Electron และมีประสิทธิภาพขณะรันสูงกว่า
    • มนุษย์ไม่จำเป็นต้องเรียน Rust ก็ยังไปถึงผลลัพธ์นั้นได้
  • โปรเจกต์ถัดไปจึงไม่จำเป็นต้องตั้ง Python เป็นค่าเริ่มต้นเสมอไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

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

  • แปลกใจที่อ่านคอมเมนต์ช่วงแรก ๆ แล้วยังไม่เห็นใครพูดถึงเรื่อง ข้อมูลฝึก เลย Python มีอยู่ในข้อมูลฝึกเยอะมาก
    AI อาจเขียน Brainfuck ได้เหมือนกัน แต่ผมไม่คิดว่าผลลัพธ์จะออกมาแบบเดียวกับตอนใช้ Python
    คำถามต่อจากนั้นคือ: ตอนนี้มี AI แล้ว ทำไมเรายังต้องแคร์เรื่องภาษา ก่อนที่มันจะจำเป็นจริง ๆ?

    • เพิ่งอยากกลับไปใช้ Perl อีกครั้งหลังจากห่างไป 5 ปี และต้องการวิธีที่ง่ายมาก ๆ สำหรับรันพร็อกซีที่กำลังทำด้วย Go พร้อมเขียน integration test หลายตัว
      ผมให้ Claude Code เขียนไปเกือบทั้งหมด แล้ว Claude จัดการ Perl ได้ดีมาก พอบอกว่าอย่าแตะ CPAN และใช้แค่ standard library ของ Perl มันก็มีทั้ง HTTP client, TLS, JSON ในตัวครบ และสามารถแทนงานที่ปกติผมคงทำด้วยเชลล์สคริปต์ได้ด้วยวิธีที่เสถียรและง่ายกว่ามาก
      เพราะ Perl แทบไม่ได้เปลี่ยนไปมากและมีข้อมูลฝึกเยอะ Claude เลยดูจะใช้ Perl ได้ดีทีเดียวในสถานการณ์ที่ปกติอาจนึกถึงเชลล์สคริปต์
    • น่าแปลกที่ LLM กลับ ให้เหตุผลกับ Python ได้แย่กว่าภาษาโปรแกรมยอดนิยมอื่นมากในงานเขียนโค้ดแบบเอเจนต์
      ข้อมูลอยู่ที่นี่: https://gertlabs.com/rankings?mode=agentic_coding
    • ใช้ Go ไปเลยก็ได้ LLM เจอ Go มาเยอะ เขียนได้ดี คอมไพล์แทบจะทันที และยังได้ข้อดีทั้งหมดของภาษาคอมไพล์ที่มี type
      ผมเคยสร้างโค้ดเบส Python ขนาดใหญ่ด้วย AI แล้ว LLM เดาอาร์กิวเมนต์หรือรูปแบบของดิกชันนารีผิดอยู่เรื่อย ๆ เครื่องมืออย่าง unit test หรือ pydantic ช่วยได้ก็จริง แต่เลี่ยง runtime error แบบนั้นไปเลยน่าจะดีกว่า
    • ข้อมูลฝึกอย่างเดียวตอบทุกอย่างไม่ได้ LLM เก่งมากในการแปลไปเป็นภาษาโปรแกรมอื่น ซึ่งก็สมเหตุสมผลเมื่อคิดว่ามันสืบทอดมาจากระบบแปลข้อความ
      ผมได้ผลลัพธ์ที่ยอดเยี่ยมแม้กับภาษาที่มีโค้ดสาธารณะค่อนข้างน้อย อุปสรรคใหญ่กว่าคือ LLM ชอบลอกสำนวนยอดนิยมของภาษาเป้าหมาย และถ้าเป็นภาษาแบบ “enterprise” อย่าง Java หรือ C# ปริมาณ boilerplate code ที่ไร้ประโยชน์อาจพุ่งขึ้นทันที แบบนั้นเสี่ยงที่ผลลัพธ์จะเกินขนาด context window ที่ใช้งานได้และทำให้คุณภาพตกลง
    • ถ้าปล่อยให้ AI สร้างโค้ดแบบ open loop ข้อมูลฝึกอาจสำคัญ เพราะใน Python มีโอกาสสูงที่ใครสักคนเคยเขียนโค้ดคล้ายสิ่งที่คุณขอไว้แล้ว
      แต่ถ้าเอเจนต์เป็นคนเขียนโค้ด ลองคอมไพล์ ดูข้อความผิดพลาดแบบละเอียด แล้วค่อยปรับโค้ดตามข้อความเหล่านั้น ผลลัพธ์จะมีคุณภาพสูงกว่า diagnostic ของ rustc ดีมาก และถึงแม้ Python หรือ JavaScript/TypeScript จะมีเยอะกว่า ตอนนี้บนอินเทอร์เน็ตก็มีโค้ด Rust มากพอแล้ว

  • เหตุผลที่ใช้ Python ก็เพราะผมใช้มันมามากกว่า 10 ปี รู้วิธีดีบัก และพอเอเจนต์เขียนโค้ดเสร็จ ผมสามารถดมกลิ่นได้ภายใน 10 วินาทีว่ามันกำลังจะพาไปสู่หายนะใหญ่หรือเปล่า
    ถ้าเป็นภาษาอื่นจะไม่เป็นแบบนั้น และต้องกลับไปเรียนรู้อีกเยอะ ต่อให้ AI ปล่อยโค้ดออกมาเร็วมาก ผมก็ยังชอบ Python ที่อย่างน้อยทำให้รู้สึกว่ายังคุมอะไรได้อยู่บ้าง ถ้าเป็น Go หรือ Rust มันคงไม่เหมือน AI-assisted programming แต่จะเหมือน “vibe coding” แบบ YOLO ใส่ทั้งโปรดักต์มากกว่า

    • ผมเริ่มใช้ Rust ก็เพราะยุคเอเจนต์นี่แหละ แต่ประสบการณ์ที่สะสมจากภาษาอื่นยังส่งต่อมาได้ และช่วยให้ผมมองออกว่าอะไรคือ code smell และสถาปัตยกรรมที่แย่
      เรื่อง memory safety ต้องเรียนเพิ่มเพราะยังไม่รู้ว่าอะไร “ถูกต้อง” แต่ที่เหลือไปได้ค่อนข้างลื่น
      ไวยากรณ์จะค่อย ๆ ถอยไปอยู่ฉากหลัง แล้วคุณจะโฟกัสกับเรื่องระดับสูงขึ้นและสำรวจเส้นทางใหม่ ๆ ได้ ถ้าลองดูสักครั้ง คุณอาจประหลาดใจแบบดี ๆ ว่าประสบการณ์เดิมถ่ายโอนมาได้มากแค่ไหน
    • ผมก็คล้ายกัน โค้ด Python ที่ AI สร้างขึ้นนี่ แค่ดูไม่กี่บรรทัดก็พอจับกลิ่นได้แล้วว่ามั่วหรือเปล่า เลยยังใช้ Python กับโปรเจกต์ส่วนใหญ่ต่อไป

  • ถ้า AI เขียนหนังสือให้ แล้วทำไมเรายังต้องใช้สมอง?

    • ไม่ใช่เรื่องที่ควรหัวเราะนะ โมเดลดีขึ้นมากเมื่อเทียบกับเดือนก่อน และค่าโทเคนก็ลดลงด้วย LLM ก็เหมือนคอมไพเลอร์สำหรับสมอง
      /s

  • ทำไมต้องหยุดแค่ให้ AI ใช้ Rust? ถ้าทุกอย่างคือ vibe coding และเราไม่ทำ code review กันแล้ว ก็ให้ LLM ออกแบบภาษาแบบสั้นสุด ๆ หนาแน่นสุด ๆ ที่สร้างมาเพื่อ ลดการใช้โทเคน และเพิ่มความเร็วอย่างเดียวไปเลย
    คอมเมนต์นี้ลงท้ายด้วย /s แบบตั้งใจแค่บางส่วน

    • ทำไมต้องหยุดแค่เขียนโค้ด? เราทุกคนควรสร้าง ชิป ASIC แบบคัสตอมกันไปเลย และถ้าไม่มี fab อย่างน้อยก็ต้องเล่น FPGA

  • อาจนอกประเด็นนิดหน่อย แต่ผมไม่เข้าใจจริง ๆ ว่าทำไมทุกวันนี้คนยังโพสต์บทความลง Medium กันอยู่
    ประสบการณ์การอ่านแย่มาก ป๊อปอัปเต็มหน้าจอมันบังประโยคที่กำลังอ่านอยู่แบบตรง ๆ จนผมอ่านบทความนี้ไม่จบ
    มีแรงจูงใจอะไรบางอย่างที่ผมมองไม่เห็นหรือเปล่า?

    • ไม่มีอะไรที่อ่านผ่านเบราว์เซอร์แล้วจะมอบประสบการณ์การอ่านที่ยอดเยี่ยมและดีที่สุดแบบเดียวกันให้ทุกคนได้ในท้ายที่สุด โมเดลเว็บสมัยใหม่มันขัดกับเรื่องนั้นเอง
      หน้า HTML ธรรมดาแบบไม่มี CSS เกือบจะเป็นประสบการณ์การอ่านที่สมบูรณ์แบบอยู่แล้ว ปัญหาคือแทบไม่มีใครเผยแพร่แบบนั้น เพราะเว็บกลายเป็นแพลตฟอร์มสิ่งพิมพ์ที่ผู้เขียนแข่งขันและใส่ใจกันเอง โปรโตคอลข้อความล้วนที่ผู้ใช้ควบคุมได้จะเข้าใกล้ “ประสบการณ์การอ่านที่ดีที่สุดสำหรับทุกคน” มากกว่า เว็บเองก็เป็นแบบนั้นได้ แต่ส่วนใหญ่ไม่เป็น
      ผมเลิกพยายามอ่านบทความยาว ๆ ในเบราว์เซอร์แล้ว ถ้าดึงข้อความล้วนที่เกี่ยวข้อง หรือแม้แต่ข้อความแบบมีโครงสร้าง ออกมาอ่านในเอดิเตอร์ของตัวเองได้ง่าย ๆ จะอ่านในเบราว์เซอร์ไปทำไม? ผมควบคุมฟอนต์ สี การนำทาง และอย่างอื่นได้เอง เบราว์เซอร์เป็นแค่ช่องทางส่งผ่าน ไม่ใช่สภาพแวดล้อมสำหรับอ่าน การปฏิบัติต่อมันแบบนั้นเป็นแค่นิสัย ไม่ใช่ความจำเป็น
      นานมากแล้วที่ผมไม่เขียนอะไรยาวเกินสามคำข้างนอกเอดิเตอร์ เพราะในนั้นมีทุกอย่างที่ต้องใช้แล้ว ทั้งตัวตรวจสะกด พจนานุกรมคำพ้อง เครื่องมือดูรากศัพท์ การแปล การเข้าถึงโน้ตทั้งหมดของผม รวมถึงการเชื่อมกับ LLM ถ้าลองสักวันหนึ่ง คุณอาจรู้สึกเป็นอิสระมาก แล้วก็อาจเลิกอ่านงานยาว ๆ ในเบราว์เซอร์ไปด้วย

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

    • เดาที่ฟังขึ้นที่สุดคือความเคยชิน บางคนมีความภักดีต่อแบรนด์สูงมาก และต้องขยับตามสิ่งที่คนอื่นกำลังทำและวิธีที่เขาทำกัน
      จริง ๆ แล้วโพสต์ที่ไหนก็ไม่สำคัญ แค่ให้ URL มาก็พอ แต่ไม่ใช่ทุกคนจะทำตัวแบบนั้น

    • มันดูเหมือนวิวัฒนาการล่าสุดของแพลตฟอร์มบล็อกที่เป็นมิตรกับนักเขียน ผูกเข้ากับรูปแบบจดหมายข่าวได้ง่ายกว่า WordPress และก็ทำเงินจาก ระดับเสียเงิน ได้ง่ายกว่าด้วย

    • ลองใช้ Scribe ซึ่งเป็นฟรอนต์เอนด์ทางเลือกของ Medium แล้วจะดีขึ้นมาก:
      https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...

      https://sr.ht/~edwardloveall/Scribe/
      https://libredirect.github.io/

  • Python มี ecosystem ที่โตเต็มที่กว่า Rust มาก โดยเฉพาะทาง AI/แมชชีนเลิร์นนิง
    ผมเคยเจอ crate ของ Rust ที่อ้างว่า implement อัลกอริทึมแมชชีนเลิร์นนิงบางอย่าง แต่ใช้งานจริงกลับไม่ถูกต้อง ถึงอย่างนั้นก็ยังให้ Claude เขียนตัวแทนขึ้นมาใหม่ได้
    พอทำงานร่วมกับ AI ผมมองว่าการบังคับความถูกต้องในระดับ type system เป็นไอเดียที่ดี เลยเลือกภาษาอย่าง C# หรือ Rust บ่อยกว่า Python แม้ว่า Python จะชัดเจนว่าเป็นเครื่องมือที่เหมาะกับงานบางอย่าง

    • ผมเลือก Rust แทบตลอด ช่วงหลังเพิ่งทำปลั๊กอินให้ของบางอย่างที่เขียนด้วย Go
      จะใช้ Rust ก็ได้ แต่ผมรู้สึกว่าถ้าผลงานมันออกมาดี คนอื่นจะได้ประโยชน์มากกว่าจากการใช้ toolchain เดียวกัน ดังนั้น Go จึงเหมาะกว่า
      เหตุผลหลักคือคุณต้องอ่านมันได้เมื่อจำเป็น และ ecosystem ปลายทางก็มีภาษาที่มันคาดหวังอยู่ ชุมชน data science บางส่วนเลือก R, MatLab, Julia, Python, Mojo ก็ไม่ได้ขึ้นกับว่าอะไรเหนือกว่าทางเทคนิค แต่ขึ้นกับว่าเพื่อนร่วมวงการเขาใช้อะไรกัน
    • ผมคิดว่ากรณีใช้งานเดียวจริง ๆ คือการห่อไลบรารี C++ ระดับล่างอย่างพวกไลบรารีแมชชีนเลิร์นนิง เพราะของแบบนั้นทำซ้ำใหม่ได้ยากมากจริง ๆ
    • มีเหตุผลอยู่หลายข้อว่าทำไมการบังคับด้วย type system ถึงดีกับการใช้ AI
      ผมเดาเอาว่า ภาษาที่มี type มักมี language server ที่เร็วและดีกว่า ทำให้แก้ไขโค้ดผ่านการใช้เครื่องมือได้มีประสิทธิภาพกว่า
      แล้วตอนที่มนุษย์ต้องเข้ามาตรวจหรือแก้โค้ดด้วยตัวเอง strong types ก็ช่วยให้หาทิศทางในสปาเกตตีโค้ดได้ง่ายขึ้นมาก
    • เรื่อง การรองรับไลบรารี สำหรับ AI/แมชชีนเลิร์นนิง นี่เป็นจุดที่พูดได้เต็มปากจริง ๆ ถึงอย่างนั้นงานแบ็กเอนด์ทุกวันนี้ผมก็ไปทาง Rust/TypeScript บ่อยขึ้น แม้ว่าจะชอบ Django มากก็ตาม
    • ถ้าจะออกจาก ecosystem ของ Python และจะปล่อยให้ AI จัดการ dependency หรือทำ polyfill ให้ ผมว่าข้ามไปทาง OCaml/F# เลยยังจะดีกว่า Rust
      แบบนั้นจะได้ข้อดีของ garbage collection และ strong types

  • ณ ตอนนี้ เหตุผลที่ใช้ Python ก็ยังเหมือนกับเหตุผลเวลามนุษย์เขียนเองทุกประการ คือมีคนรู้จัก Python มากกว่า Zig ดังนั้นมนุษย์จึงอ่านและแก้โค้ดได้ง่ายกว่า
    ผมเข้าใจประเด็นของบทความนะ แต่ผมว่ายังไปไม่ถึงขั้นนั้น

    • โลกที่ระบบอัตโนมัติเขียนในภาษาที่มนุษย์ไม่เข้าใจ ทำให้นึกถึงโรงงานอัตโนมัติในจีนที่มืดสนิทไปหมด มนุษย์หลงทางและสับสน แต่หุ่นยนต์กลับอยู่ในนั้นได้อย่างสบาย

  • “แอปที่ปล่อยขึ้นโปรดักชันด้วยภาษาที่ไม่มีใครในทีมรู้เลย” ฟังดูดีนะ อีกไม่นานนักเราคงได้ย้อนกลับมามองเรื่องแบบนี้

    • ก่อนมี AI ก็มีเรื่องแบบนี้อยู่แล้ว เมื่อ 10 ปีก่อนมีคนเขียนเครื่องมือสำคัญด้วยภาษาสุ่ม ๆ แล้วคนที่เหลือต้องมารับช่วงดูแลต่อ สุดท้ายก็ผ่านไปได้อยู่ดี
    • อาจเป็นสิ่งเดียวในโลกที่น่ากลัวกว่า แอป Electron ที่พวกเขากำลังจะเอามาแทนก็ได้
    • ก็แค่ย้ายงานในอีก 12–18 เดือน แล้วมันก็จะกลายเป็นปัญหาของคนอื่น

  • ข้อความที่ว่า “นักวิจัยของ Anthropic ชื่อ Nicholas Carlini ประสาน Claude agent แบบขนาน 16 ตัวเพื่อเขียนคอมไพเลอร์ C ระดับโปรดักชันด้วย Rust” ไม่เป็นความจริง
    คอมไพเลอร์นั้นสร้างโค้ดที่ด้อยกว่า gcc/clang มาก จึงแทบ ไร้ประโยชน์