Bun เวอร์ชันเขียนใหม่ด้วย Rust แบบทดลอง แตะความเข้ากันได้ของการทดสอบ 99.8% บน Linux x64 glibc
(twitter.com/jarredsumner)- เวอร์ชันเขียนใหม่ด้วย Rust ของ Bun ผ่าน 99.8% ของชุดทดสอบเดิมบนสภาพแวดล้อม Linux x64 glibc
- โค้ดเบสเป็น “โค้ดเบสเดียวกันโดยพื้นฐาน” และการย้ายไป Rust ทำให้คอมไพเลอร์บังคับ วงจรชีวิตของชนิดข้อมูล และสามารถใช้ destructor ได้ในเวลาที่จำเป็น
- ส่วนที่ไม่ปลอดภัยชัดเจนขึ้นด้วย unsafe ของ Rust จึงมีผลช่วยผลักดันให้เกิดการรีแฟกเตอร์
- เหตุผลที่เขียนใหม่คือเหนื่อยกับการใช้เวลาจำนวนมากไปกับการกังวลและแก้ไข memory leak, การแครช และปัญหาความเสถียร และต้องการให้ภาษามีเครื่องมือที่ทรงพลังกว่านี้เพื่อป้องกันปัญหาเหล่านั้น
- ขนาดทั้งหมดถูกอธิบายว่าเป็นการเขียนใหม่ 960,000 LOC และตอนนี้ผ่านชุดทดสอบบน Linux แล้ว โดยแพลตฟอร์มอื่นจะตามมาในไม่ช้า
สถานะของการเขียนใหม่ด้วย Rust
- เวอร์ชันเขียนใหม่ด้วย Rust ของ Bun ผ่าน 99.8% ของชุดทดสอบเดิมบนสภาพแวดล้อม Linux x64 glibc
- โค้ดเบสเป็น “โค้ดเบสเดียวกันโดยพื้นฐาน” และเมื่อเปลี่ยนมาใช้ Rust คอมไพเลอร์จะบังคับวงจรชีวิตของชนิดข้อมูลและทำให้สามารถใช้ destructor ได้ในเวลาที่จำเป็น
- ส่วนที่ไม่ปลอดภัยใน Rust จะมองเห็นได้ชัดเจนขึ้นผ่าน unsafe และมีผลช่วยผลักดันให้เกิดการรีแฟกเตอร์
- เบื้องหลังการเขียนใหม่คือความเหนื่อยล้าจากการใช้เวลามากไปกับการกังวลและแก้ไข memory leak, การแครช และปัญหาความเสถียร พร้อมกับความต้องการให้ภาษามีเครื่องมือที่ทรงพลังกว่านี้เพื่อป้องกันปัญหาเหล่านี้
- ขนาดทั้งหมดถูกอธิบายว่าเป็นการเขียนใหม่ 960,000 LOC และโค้ดก็ใช้งานได้จริง ผ่านชุดทดสอบบน Linux แล้ว และแพลตฟอร์มอื่นจะเป็นเป้าหมายต่อไปในไม่ช้า
สิ่งที่จะเปิดเผยต่อไปและคำตอบเกี่ยวกับการบิลด์
- ความหมายที่มีต่อ Bun, เบนช์มาร์ก, การใช้หน่วยความจำ, ความสามารถในการบำรุงรักษาในอนาคต และกระบวนการเขียนใหม่จริง จะกล่าวถึงในบล็อกโพสต์แยกต่างหาก
- กระบวนการเขียนใหม่ไม่ได้เป็นแค่การสั่งว่า “claude, rewrite bun in rust. make no mistakes” และงานเพื่อให้ไปถึงสถานะที่ใช้งานได้จนจบเริ่มต้นขึ้นเมื่อ 6 วันก่อน
- มีการอธิบายว่าหากทำด้วยมือจะเป็นงานปริมาณมหาศาล
- เวลาในการคอมไพล์โดยพื้นฐานแล้วใกล้เคียงกับเวอร์ชัน Zig เดิมที่ใช้ Zig compiler ซึ่งเร็วกว่า และหากใช้ upstream Zig compiler ก็กล่าวว่าพอร์ต Rust จะคอมไพล์ได้เร็วกว่า
- ประสิทธิภาพจะกล่าวถึงในบล็อกโพสต์แยกต่างหาก
- สำหรับขั้นถัดไปในการแทนที่ libc เองด้วยเวอร์ชัน Rust อย่าง frankenlibc นั้น มีการบอกว่าจะทำ libc ขึ้นมาเองก่อน
1 ความคิดเห็น
ความเห็นจาก Hacker News
มีประเด็นแบบนี้เมื่อ 4 วันก่อนด้วย: https://news.ycombinator.com/item?id=48019226
คนทำ Bun บอกว่าเป็นบรাঞ্চของตัวเอง และในตอนนั้นเธรดนั้นเป็นการตอบสนองเกินเหตุไปกับโค้ดที่ยังใช้การไม่ได้ ยังไม่เคยตัดสินใจแน่ชัดว่าจะรีไรต์ และมีโอกาสสูงมากที่โค้ดทั้งหมดจะถูกทิ้ง
เขาบอกว่าอยากดูว่าเวอร์ชันที่ใช้งานได้จะออกมาเป็นอย่างไร ประสิทธิภาพและการดูแลรักษาจะเป็นอย่างไร และยากแค่ไหนที่จะผ่าน Bun test suite เพื่อจะได้เปรียบเทียบ เวอร์ชัน Rust กับเวอร์ชัน Zig แบบวางข้างกัน
cargo checkเจอ compiler error มากกว่า 16,000 รายการ และยังพิมพ์เลขเวอร์ชันหรือรัน JavaScript ไม่ได้เลยเขาเองก็ไม่คิดว่าจะใช้งานได้เร็วขนาดนี้ และไม่คิดว่าประสิทธิภาพจะสู้ได้ขนาดนี้ โดยรายละเอียดจะมีในบล็อกโพสต์ภายหลัง
หลังถูก Anthropic ซื้อกิจการก็น่าจะคาดไว้ได้ แต่ก็ยังน่าผิดหวังอยู่ดี ไม่ได้ต่อต้านเทคโนโลยี large language model เอง แต่รังเกียจวิธีที่บริษัท “AI” พวกนี้กวาดกินทั้งอุตสาหกรรมซอฟต์แวร์และสังคมโดยรวมเพื่อสะสมอำนาจ และกำลังสร้างการพึ่งพาที่ไม่ดีต่อสุขภาพอย่างมาก
เราต้องมองไปอีกหลายตาและเตรียม ซอฟต์แวร์สแตกและชุมชนที่ไม่มี slop เอาไว้ ซึ่งรวมถึง Zig และ ecosystem ของมันด้วย ถึงแม้เราหรือคนรุ่นหลังอาจอยู่แบบไร้ slop อย่างสมบูรณ์ไม่ได้ แต่การทำให้มั่นใจว่าวัฒนธรรมคอมพิวติ้งที่ยั่งยืนพร้อมเสรีภาพในความหมายของ freedom จะยังคงอยู่ สำคัญกว่าที่เคย
ทำได้เร็วขนาดนี้น่าประทับใจมาก ผมเองกำลังทำโปรเจกต์ พอร์ต TypeScript ไปเป็น Rust มา 5 เดือนแล้ว และไม่มี Mythos หรือสิทธิ์เข้าถึงโทเค็นแบบไม่จำกัด
ถึงอย่างนั้นก็เกือบแตะอัตราผ่าน 100% แล้ว และตอนที่เขียนนี้อยู่ที่ 99.6%: https://tsz.dev
Rust เหมาะมากกับการเขียนโค้ดด้วย large language model เพราะระบบ type ที่เข้มงวดช่วยลดความผิดพลาดโง่ ๆ ที่ภาษาอื่นอาจปล่อยผ่านได้
แต่การใช้ large language model เขียนโค้ดก็ไม่ได้ทำให้วิสัยทัศน์ด้านการออกแบบและการตัดสินใจเรื่อง trade-off ที่จำเป็นต่อการสร้างโปรเจกต์หายไป ดังนั้น Jarred และทีมจึงเป็นคนที่เหมาะจะใช้ large language model กับโค้ดจำนวนมหาศาลได้อย่างมีประสิทธิภาพ
ในอีกด้าน Rust เป็นภาษาที่ซับซ้อน จึงเกิด หิมะถล่มของการรีแฟกเตอร์ ได้ง่าย ที่การเปลี่ยนแปลงเล็กน้อยบังคับให้ต้องรีแฟกเตอร์โค้ดที่อยู่ไกลออกไป ถ้าสถาปัตยกรรมตั้งต้นไม่ดีหรือไม่เพียงพอ ก็มีความเสี่ยงสูงที่โค้ดเบสจะกลายเป็นสปาเกตตีมากขึ้นเรื่อย ๆ เมื่อ large language model ค่อย ๆ ขยายมันแบบทีละน้อยตามที่มักทำ
สุดท้ายก็เลยกังวลว่าอาจได้โปรแกรมที่ compile ได้ รันได้ แต่คนอ่านหรือดูแลรักษาไม่ได้
ทั้งหมดนั้นทำได้ด้วยแค่บัญชี Codex เดือนละ $200 จำนวน 8 บัญชี ไม่มี Mythos
ผมก็เห็นข้อดีของ Rust ตรงนี้เหมือนกัน และจากประสบการณ์กับ Postgres คิดว่าน่าจะตัดสินใจด้านออกแบบได้ดีในหลายส่วนที่คนติดปัญหากับ pg มานาน AI ทำให้รู้สึกตื่นเต้นที่การปรับปรุงซอฟต์แวร์ซับซ้อนซึ่งเมื่อก่อนแทบไม่คุ้มทำ เริ่มเป็นไปได้มากขึ้น
[0] https://github.com/malisper/pgrust
[1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
แค่การรักษาหรือสร้างขอบเขตที่สะอาดก็ไม่ใช่งานที่ลื่นไหลอีกต่อไป แต่กลายเป็นการรีวิวที่เจ็บปวด แล้วสุดท้ายก็ไหลไปสู่โหมดผัดวันประกันพรุ่ง
ผมไม่มีหลักฐานแน่นมาก แต่ไม่อยากไปยุ่งกับ Bun อีกแล้ว มันเป็นเรื่องความรู้สึกมากกว่า แต่ผมทั้งเชื่อใจและสนับสนุนไม่ลง
เพื่อจะใช้ประโยชน์จากการรีไรต์ด้วย LLM ถึงกับ fork Zig และทำสิ่งอย่าง การคอมไพล์แบบไม่กำหนดแน่นอน ที่ทีม Zig ดูไม่อยากได้อย่างชัดเจน
ตอนนี้ก็เหมือนกำลังงอแงแล้วทำ LLM rewrite เป็น Rust อีก เป็นไปได้ว่าปรัชญาการออกแบบของ Zig ที่บังคับให้ต้องตัดสินใจยากแต่แม่นยำต่างหากที่พาโปรเจกต์มาถึงจุดนี้ และการรีไรต์เป็น Rust อาจเป็นจุดเริ่มต้นของความเสื่อมถอยจริง ๆ ก็ได้
มันเป็นการตัดสินใจที่ใกล้การเมืองมากกว่าเทคนิค แต่ Bun ดูเหมือนถูก Claude ค้ำไว้เต็มตัว จะไม่แปลกใจเลยถ้าสโลแกนการตลาดถัดไปของ Anthropic คือ “Claude Mythos รีไรต์ JS runtime ขนาด 950K LOC ชั้นนำเป็น Rust”
เธรด Twitter ที่ลิงก์ไว้ให้ เหตุผลทางเทคนิคที่ชัดเจน
การทำงานใน ecosystem ของ JS/NPM ก็พึ่งพาศรัทธาล้วน ๆ ต่อ dependency ที่ไม่ได้รับการตรวจสอบอยู่แล้วมากพอสมควร และก่อนหรือหลัง LLM rewrite มันก็ดูไม่ต่างกัน ถ้ามันยังตอบโจทย์เป้าหมายเดิมและสัญญา API ได้ แล้วต่างกันตรงไหน? ก็ยังสงสัยด้วยว่าคุณเคยนั่งอ่าน source เดิมแบบละเอียดจริง ๆ หรือเปล่า
มันมาในแนวว่าจะโค่นคู่แข่งเดิมให้ดีกว่า เร็วกว่า แกร่งกว่า ทุกครั้ง แต่ก็ชัดมากว่าจะไม่มีวันทำตาม Keep It Simple Stupid
และก็ชัดเจนด้วยว่าในอนาคตอันใกล้ ที่ที่เราจะได้เห็นมันใน production จริงคงมีแต่สตาร์ตอัป YC ที่ไหม้กันทีละรายเหมือนราดสารเร่ง ตอนนี้ดูเหมือนเลยจุดที่จะย้อนกลับแล้ว
Anthropic ซื้อ Bun ไปด้วยความพยายามค่อนข้างงี่เง่าที่จะมาแก้ปัญหา “ประสิทธิภาพ” ของตัวเอง โดยดูเหมือนไม่รู้ว่าปัญหาคือโค้ดมันแย่มาตั้งแต่แรก
ถึงอย่างนั้นการได้ดึงนักพัฒนาที่เก่งจริงมาร่วมก็น่าจะช่วยได้บ้าง
แต่ในกระบวนการนั้น Bun ก็ขยับจากโปรเจกต์สาธารณะไปใกล้เคียงเครื่องมือภายในของ Anthropic มากขึ้น และตอนนี้เหมือนถูกประคบด้วยเงิน AI จนเสียโฟกัสไปพอสมควร
หวังว่าพอฟองสบู่แตก อย่างน้อยความพยายามที่ลงไปกับ Bun จะกู้กลับมาได้บ้าง เพราะไม่น่าเชื่อว่า Anthropic จะดูแลมันในระยะยาว พวกเขาไม่ใช่บริษัทที่ขายบริการสนับสนุน runtime และก็ไม่ได้มีสเกลระดับ Google มากพอจะดูแล runtime ควบคู่ไปด้วย
ถ้าตัดประเด็น AI ออกไปชั่วคราว ผมคิดว่านี่เป็นการเปลี่ยนแปลงที่ดี
Bun ตอนใช้ Zig มี แครชและบั๊กหน่วยความจำ เยอะมากผิดปกติ ซึ่งต่างจาก Deno ที่ใช้ Rust
แน่นอนว่าถ้า Rust port ของ Bun มี
unsafeเยอะ มันก็คงไม่ใช่ว่าทุกอย่างจะหายดีเหมือนเวทมนตร์ แต่ก็น่าจะดีขึ้นประเด็นที่ว่าส่วนที่น่าเกลียดจะมองเห็นชัดขึ้นผ่าน
unsafeจนชวนให้รีแฟกเตอร์ ดูเหมือนไม่ใช่แค่เรื่องของภาษาอย่างเดียว แต่ Bun เองก็อาจมีส่วนทำให้เกิดขึ้นด้วยถ้าใช่ มันก็แปลว่าแทบเป็นไปไม่ได้เลยที่จะสร้างซอฟต์แวร์คุณภาพสูงด้วยเครื่องมือแบบนั้นไม่ใช่หรือ? ทั้งที่มีของคุณภาพดีมากมายสร้างด้วย C/C++ เลยสงสัยว่า Zig ทำอะไรผิด
unsafeถูกทำเครื่องหมายไว้อย่างชัดเจน เลยหาได้ง่าย และเกิดเป็นรายการปัญหาที่ต้องแก้แบบเป็นธรรมชาติเรื่องนี้ใช้เวลา 6 วัน เอง ต่อให้สุดท้ายจะไม่กลายเป็นผลลัพธ์ที่มีความหมายมากนัก แต่มันก็แสดงให้เห็นว่าตอนนี้และต่อจากนี้ โทเค็นกับปริมาณงานจะเชื่อมโยงกันอย่างไร
มันจะยิ่งแข่งขันยากขึ้นกับบุคคลหรือบริษัทที่มีทรัพยากรคอมพิวต์มากกว่า เพราะพวกเขาจะทำสิ่งที่ผมทำไม่ได้ได้เลย
เมื่อใช้โค้ดเบสที่เสร็จสมบูรณ์เป็นตัวอย่างและใช้ test suite ตรวจสอบ ก็ทำซ้ำไปสู่เป้าหมายที่ต้องการได้ง่ายกว่ามาก โมเดลมองเห็นอยู่แล้วว่าจุดหมายคืออะไร และเห็นด้วยว่ามีวิธีทำสำเร็จอยู่แล้วอย่างน้อยหนึ่งแบบ จึงเป็นปัญหาที่ง่ายกว่าการเริ่มจากสเปกมาก
ลงทุนด้วยทุน สร้างจากเทคนิคที่เข้าใจดีและขยายได้ แล้วเสียบไฟก็ได้มูลค่าออกมา
ประเด็นคือ ในโลกสมัยใหม่มันคงไม่ลงเอยเป็นการแบ่งว่า “มี” กับ “ไม่มี” แบบที่ไฟฟ้าก็ไม่ได้เป็นเช่นนั้น
สิ่งที่เห็นตอนนี้คือ “ว้าว ตอนนี้ฉันเป็นวิศวกร 10x แล้ว!” แล้วก็ปล่อยโค้ดออกมามากขึ้นโดยไม่มีทิศทางหรือรสนิยมที่ชัดเจน งานส่วนใหญ่ที่อิง large language model ในตอนนี้ดูเป็นแค่สัญญาณรบกวน
ไม่รู้เคยลอง Qwen 3.6 27b หรือยัง แต่มันทำอะไรได้บ้าคลั่งมากเมื่อเทียบกับขนาด ถ้าจัดการ context ดี ๆ โปรเจกต์เล็ก ๆ ก็ทำแบบ vibe coding 100% ได้เลย
โมเดลพวกนี้สุดท้ายก็จะไหลลงไปสู่การแข่งขันด้านราคาเหมือนคอมพิวต์
หลายคนรับเรื่องนี้แบบตรงตัว แต่ส่วนใหญ่ที่ทำได้ก็เพราะมี test suite ที่กว้างขวางและครอบคลุมเกินมาตรฐานเดิมมาก ที่สร้างไว้ก่อนแล้ว
ตอนนำไปทำการตลาดในภายหลัง ก็คงดีถ้าจะใส่ด้วยว่ามีแรงงานมนุษย์มหาศาลแค่ไหนในการออกแบบและคัดสรร test suite ที่ทำให้ความเร็วระดับนี้เกิดขึ้นได้
test suite ทำงานคล้ายสภาพแวดล้อมที่เกือบสมบูรณ์แบบสำหรับ large language model รุ่นปัจจุบันมาก ถ้ามันครอบคลุมพอ ก็จะกลายเป็นสเปกที่เปิดทางให้เอเจนต์ลงมือทำในแบบที่ต้องการได้ และในที่นี้เป้าหมายก็คือ Rust
ถ้าเป็นชุดทดสอบที่ทำมาดีแบบโปรเจกต์อย่าง Bun บางกรณีก็รู้สึกว่าต่อให้ทิ้ง source เดิมทั้งหมดไป แล้วให้เข้าถึงแค่ test อย่างเดียว ก็ยังอาจ implement ทั้งระบบขึ้นใหม่ได้ตั้งแต่ต้น
ถ้า test suite เองก็มีส่วนต้องรับผิดชอบด้วย ก็อยากรู้ด้วยว่ามันมีนัยอย่างไรต่อ Rust port
แล้ว เวลานับแสนชั่วโมง ที่ลงไปกับสถาปัตยกรรมเดิมและ test suite ที่ทำให้สิ่งนี้เกิดขึ้นได้จะให้มองข้ามไปหรือ
นี่น่าจะเป็นกรณีศึกษาเตือนใจสำหรับการพอร์ตเป็น Rust ด้วย AI
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...
Claude code C compiler ผ่าน gcc test ได้ 100% แต่กลับรัน
hello worldไม่ได้ด้วยซ้ำถ้าให้แค่ logical test มันก็จะไม่สนใจเรื่องความเร็วเลย แต่ถ้ารวมการวัดความเร็วไว้ใน test และบอกให้ทำให้ตรงเป้าด้าน performance มันก็จะทำแบบนั้นด้วย
นี่เป็นข้อผิดพลาดประเภทเดียวกับความพลาดอื่น ๆ ของ large language model คือมันไม่มีบริบทเชิงสามัญสำนึกว่ามนุษย์เห็นอะไรสำคัญ ถ้าไม่บังคับขอบเขต มันก็จะมองข้าม
เป็นยุคสมัยที่เหลือเชื่อจริง ๆ ที่ยังได้มีชีวิตอยู่
พลวัตพื้นฐานของทั้งอุตสาหกรรมและอาชีพเปลี่ยนไปในเวลาสั้นมาก แทบจะชั่วข้ามคืน
บางวันผมตื่นเต้นมากกับสิ่งที่ตอนนี้ทำได้เยอะแยะ ผมแทบสร้างอะไรก็ได้เกือบทันที และ 100% ของสิ่งที่เคยฝันอยากทำด้วยซอฟต์แวร์อาจกลายเป็นจริงได้
บางวันก็กลัวว่าจะเกิดอะไรขึ้นกับ ตลาดงาน
จู่ ๆ เรากลับได้ของจำนวนมากด้วยต้นทุนน้อยมาก และปริมาณซอฟต์แวร์ที่โลกต้องการก็มีขีดจำกัด
บริษัททั้งหมดที่ยึดการขายซอฟต์แวร์เป็นโมเดลธุรกิจหลักจะล้มกันหมดไหม?
แล้วถ้ามีแค่บางบริษัทหรือบางรัฐบาลที่เข้าถึงโมเดลที่ดีที่สุดได้จะเกิดอะไรขึ้น?
บริษัท 100 แห่งที่มี 1 พันล้านโทเค็น จะสร้างผลิตภัณฑ์ที่ดีกว่าผู้ขายเฉพาะทางที่มี 1 แสนล้านโทเค็นได้ไหม?
vendor ซอฟต์แวร์กับ SaaS แบบ “ตัวสร้างโลโก้” น่าจะตายไปแล้วจริง แต่ตราบใดที่ระบบขายตั๋วยังไม่ถูกฝังรวมมาใน large language model รุ่นถัดไป vendor ระบบขายตั๋วก็น่าจะยังอยู่ได้ คนอาจใช้น้อยลง แต่ก็ไม่แน่ชัด
เป็นทำนองว่ามีงานให้แบ่งกันไม่มากเมื่อเทียบกับจำนวนคนที่หลั่งไหลเข้ามา และการล่มสลายก็ยิ่งเสริมเรื่องเล่านั้น
แต่ถึงจะยังเป็นนักศึกษาในตอนนั้นก็ยังพอมองออกว่าขอบเขตของซอฟต์แวร์แทบไร้ขีดจำกัด งานเชิงการรับรู้เกือบทุกอย่างที่เรายังทำด้วยมือ สามารถทำด้วยซอฟต์แวร์ได้ ผมเคยลองจะไล่รายการพวกนั้น แล้วก็พบอย่างรวดเร็วว่ามันมีสิ่งให้ทำมากมายเหลือเกิน
แถมยิ่งเราทำงานด้วยวิธีใหม่ ๆ ก็ยิ่งมีงานใหม่ ๆ ที่ไม่เคยนึกถึงโผล่มาอีก นับความเป็นไปไม่ได้เลย และเรื่องเล่าว่า “อิ่มตัว” ก็ชัดเจนว่าเกิดจากการขาดจินตนาการและความเข้าใจว่าซอฟต์แวร์คืออะไร
เพราะงั้นผมเลยรู้ว่าสาขานี้จะไม่มีวันอิ่มตัวจริง ๆ เพราะเป็นไปไม่ได้ที่สิ่งที่ควรทำเป็นซอฟต์แวร์จะหมดลง
แต่ทุกวันนี้มันต่างออกไป ต่อให้เราจะสร้างซอฟต์แวร์ใหม่เสมอ แต่ตอนนี้ผมเริ่มสงสัยว่าเราอาจเขียนซอฟต์แวร์ได้เร็วกว่าความเร็วที่เราจะจินตนาการงานใหม่ ๆ ขึ้นมาเสียอีกหรือไม่
คนทั่วไปก็คงยังช่วยตัวเองได้ด้วยโมเดลที่ตามหลังแนวหน้าหน่อย
อย่างน้อยการเฝ้าดูความพยายามแบบนี้ก็น่าสนใจ
สิ่งแรกที่ผมสงสัยมากที่สุดคือ ความครอบคลุมและคุณภาพของ test suite เดิมมันอยู่ระดับไหน ไม่ได้จะจับผิดนะ แต่ถึงจะได้ 100% ทุกแพลตฟอร์ม ผมก็ยังสงสัยว่าทีม Bun จะมั่นใจกับการย้ายระบบมากแค่ไหน
หลังเรื่อง Ubuntu coreutils เมื่อสัปดาห์ก่อน มุมมองของผมต่อ การรีไรต์เป็น Rust ที่เข้ากันได้กับการทดสอบ 99.8% แย่ลงมาก
กดเข้าไปดูทวีตที่ลิงก์ไว้แล้วรู้สึกขนลุก และตอนนี้พอเห็นอะไรแบบนี้ก็เกิดความรู้สึกตรงข้ามขึ้นมาแทน แทบอยากหาทางออกเลย