ต้องเริ่มต้นใหม่: จาก Atom ถึง Zed
(zed.dev)- ทีมที่สร้าง Atom กำลังนำเป้าหมายเดิม—เอดิเตอร์ที่เบาแต่มีความสามารถระดับ IDE—กลับมาตีโจทย์ใหม่ใน Zed บนพื้นฐานของ Rust·UI เร่งความเร็วด้วย GPU·CRDT·Tree-sitter
- ข้อจำกัดของ Atom ในปี 2017 ปรากฏชัดกว่าในเรื่อง หน่วยความจำและการขาดการควบคุมการเรนเดอร์ ของ Electron และ JavaScript มากกว่าความสามารถของทีม และนำไปสู่ข้อสรุปว่า “ต้องเริ่มต้นใหม่”
- Rust ช่วยให้ Zed จัดการหน่วยความจำที่ใช้ร่วมกันและมัลติเธรดได้ปลอดภัยขึ้น และทำให้สร้าง snapshot แบบ O(1) ที่จำเป็นต่อการทำงานเบื้องหลังได้ด้วยโครงสร้าง rope ที่ใช้ copy-on-write B-tree และ
Arc - Zed เลือกเป็นเจ้าของเลเยอร์หลักเอง เช่น GPUI, ส่วนขยาย Tree-sitter, crate
editor, multi-buffer และ SumTree เพื่อให้ควบคุมได้ละเอียด แลกกับความเร็วในการพัฒนาและต้นทุนการ onboarding - ผลลัพธ์ที่สำคัญที่สุดสำหรับผู้ใช้คือเอดิเตอร์ที่เร็ว และโครงสร้างที่ใช้ Rust กับ
cargoช่วยให้ผู้ร่วมพัฒนาโอเพนซอร์สลอง build และแก้ไขได้ง่ายขึ้น พร้อมเพิ่มความเชื่อมั่นในการ merge
วิสัยทัศน์ของ Atom สืบต่อมาถึง Zed อย่างไร
- เป้าหมายของ Zed ใกล้เคียงกับรูปแบบที่ขัดเกลาขึ้นของวิสัยทัศน์ที่ Atom มุ่งหวังตั้งแต่แรก
- เครื่องมือที่เบา เรียบง่าย และให้ความรู้สึกเหมือน text editor
- เครื่องมือที่ให้ความสามารถระดับ IDE เมื่อจำเป็น แต่ UI และประสบการณ์ใช้งานไม่ช้าหรือหนัก
- เอดิเตอร์ที่ขยายความสามารถและทำสคริปต์ได้
- ความสามารถในการขยายของ Emacs มีอิทธิพลต่อวิสัยทัศน์ช่วงแรก แต่ต้องการแนวทางที่เข้าถึง การแทนข้อความที่สมบูรณ์กว่า มากกว่าการจัดการแบบรายอักขระอย่างง่าย
- Tree-sitter เป็นพื้นฐานที่ทำให้จัดการข้อความในเชิงโครงสร้างได้มากกว่าระดับอักขระ และแม้ Zed จะยังทำสคริปต์ไม่ได้ แต่ก็มุ่งไปในทิศทางนั้น
- Atom เริ่มต้นบนพื้นฐานเทคโนโลยีเว็บ ตอนนั้นยังไม่มี Rust และมองว่าการสร้างเอดิเตอร์เนทีฟด้วย C หรือ C++ ก็ทำได้ยาก
เหตุผลที่ตัดสินใจ “เริ่มต้นใหม่” ในปี 2017
- หลังจาก Atom เปิดตัว Teletype ในปี 2017 ทีมเริ่มรู้สึกว่า ข้อจำกัดของแพลตฟอร์ม เป็นคอขวดที่ใหญ่กว่าความไม่ชำนาญของทีม
- Array ของ JavaScript ทำงานคล้าย array ของ pointer ไปยัง object ทำให้เกิดต้นทุนการไล่ตาม pointer ระหว่างวนอ่าน และควบคุมการจัดวางหน่วยความจำกับการหยุดชั่วคราวของ garbage collector ได้ยาก
- แม้แต่งานทำ line layout ให้เร็วขึ้น ก็ต้องผสมผสาน iframe, Canvas และ API วัดข้อความแบบอ้อม ๆ และงานที่ดูเรียบง่ายอย่างตำแหน่ง cursor หรือการจัดวางบรรทัดก็ซับซ้อนขึ้น
- Electron เกิดขึ้นเพื่อสร้าง Atom แต่ให้การควบคุมในระดับที่ code editor ต้องการได้ยาก
- ใช้กับแอปที่เรียบง่ายกว่าได้ แต่มีข้อเสียคือ memory footprint ใหญ่
- สำหรับ code editor ต้องการการควบคุมที่ตรงกว่านี้ในด้านการเรนเดอร์ อินพุต และการประมวลผลข้อความ
- ณ ช่วงหนึ่งในปี 2017 ทีมมองว่า Atom ไม่สามารถไปถึงระดับที่ต้องการได้ จึงเริ่มจากไอเดียเขียนแกนหลักด้วย Rust แต่ยังคงใช้ Electron เป็นเลเยอร์ presentation
เส้นทางย้ายไปสู่ Rust และการเร่งความเร็วด้วย GPU
- ตัวเลือกเทคโนโลยีของ Zed ไม่ได้เป็นพิมพ์เขียวตายตัวตั้งแต่แรก แต่ค่อย ๆ กำหนดขึ้นจากการขจัดข้อจำกัดทีละขั้น
- เริ่มจากพิจารณาแนวทางเขียนแกนหลักด้วย Rust
- ต่อมาจึงเลิกใช้ Electron และสร้าง UI framework เอง
- เคยใช้ Pathfinder แต่ช้าเกินไป จึงเรียนรู้และนำ shader กับ signed distance field ของตัวเองมาใช้
- การเร่งความเร็วด้วย GPU ไม่ได้เริ่มจากคำขวัญว่า “เอดิเตอร์เร่งด้วย GPU” แต่เลือกเพราะเห็นว่าถ้าใช้ฮาร์ดแวร์ที่คำนวณสีของแต่ละพิกเซลบนหน้าจอแบบขนานได้โดยตรง น่าจะเร็วกว่า
- Zed เลือกแนวทางควบคุมการเรนเดอร์ในระดับที่ใกล้กับการกำหนดว่าจะวาดพิกเซลบนหน้าจออย่างไร แทนการปรับ DOM node
- ตัวอย่างการปรับปรุงประสิทธิภาพคือ
find-all-matchesที่เดิมใช้เวลาประมาณ 1 วินาที และ Sublime Text ใกล้เคียง 200ms แต่ลดลงเหลือ 4ms ใน release build ด้วยโค้ดระดับสูงที่เรียกใช้ API ภายในเท่านั้น - เวลา compile ของ Rust ยังเป็นสิ่งที่น่าบ่นอยู่ แต่ความสามารถในการคาดหวังประสิทธิภาพได้แม้อยู่บน abstraction ระดับสูงช่วยในการพัฒนา Zed ได้มาก
ขอบเขตระหว่าง JavaScript/C++ และมัลติเธรดของ Rust
- Atom ก็ใช้ C++ จำนวนมาก แต่ขอบเขตระหว่างโค้ดแอปพลิเคชัน JavaScript กับโค้ดไลบรารี C++ กลายเป็นต้นทุนขนาดใหญ่
- หากจะย้ายงานไปยัง background thread ก็ต้องย้าย subsystem ที่เกี่ยวข้องลงไปเป็น C++
- หากจะใช้ shared memory ก็ต้องสร้างเลเยอร์ C++ แล้วออกแบบ JavaScript API ใหม่
- ยังต้องทำให้ดูเป็น JavaScript พร้อมรักษาคุณสมบัติเดิมไว้ด้วย
- Rust มีการออกแบบที่เป็นมิตรต่อมัลติเธรด จึงเข้ากับแนวทางที่ Zed ต้องการมากกว่า
- ช่วงแรกเคยพยายาม implement splay tree ที่มี parent pointer และแก้ไขได้ใน Rust แต่ชนกับ borrow checker ถึงขั้นสงสัยว่าจะสร้างระบบจริงได้หรือไม่
- ต่อมาขณะสร้าง copy-on-write B-tree ได้ใช้
Arcและโครงสร้างนี้กลายเป็นรูปแบบที่เข้ากับมัลติเธรดโดยธรรมชาติ - โครงสร้างเก็บข้อความพื้นฐานของ Zed คือ rope สามารถส่ง snapshot ไปยัง background thread ได้ด้วยการเพิ่ม reference count ของ
Arcเป็นหลัก
การเลือกเป็นเจ้าของทั้งสแต็กเอง
- Zed เลือกเป็นเจ้าของ block ใหญ่ ๆ เอง ตั้งแต่ Tree-sitter ที่รับผิดชอบ parsing ไปจนถึง GPUI ซึ่งเป็น UI framework เร่งความเร็วด้วย GPU
- โครงสร้างที่เป็นเจ้าของเองทำให้กำหนดและ implement พฤติกรรมที่ต้องการได้ด้วยตัวเอง
- เมื่ออยากใช้ WASM ในส่วนขยายภาษา ก็สามารถเพิ่มความสามารถนั้นเข้าไปใน Tree-sitter ได้
- ไม่ต้องฝากวิธีเรนเดอร์ข้อความที่สำคัญต่อ text editor ไว้กับ UI framework ภายนอก
- GPUI เริ่มต้นในปี 2019 และในเวลานั้น UI framework ที่มีอยู่ยังไม่ตอบโจทย์พฤติกรรมที่ Zed ต้องการ หรือทีมยังเข้าใจไม่มากพอ
- วิธีทำความเข้าใจ primitive ระดับล่างเองแล้วสร้างระบบขึ้นมา สำหรับ GPUI แล้วใกล้เคียงกับ กลยุทธ์เพื่อความอยู่รอด
- ต้นทุนก็ชัดเจน
- ใช้เวลานานในการสร้างเอง
- ความเร็วในการพัฒนาช้าลง
- เพราะไม่ได้ใช้ framework ที่คนรู้จักแพร่หลาย พนักงานใหม่ต้องเรียนรู้ codebase ราว 300,000 บรรทัดตั้งแต่ต้น
- ในขณะเดียวกัน คนที่เขียนโค้ดนั้นยังอยู่ในทีมและสามารถอธิบายให้สมาชิกใหม่ได้ และมองว่าเมื่อเวลาผ่านไป ต้นทุนของการเป็นเจ้าของเองจะลดลง ส่วนข้อดีจะสะสมเพิ่มขึ้น
- เริ่มมีกรณีที่แอปอื่นถูกสร้างบน GPUI เช่น loungy
จุดที่ควรยกระดับความสมบูรณ์ และจุดที่ควรผ่านไปอย่างรวดเร็ว
- มาตรฐานของทีม Zed คือสร้างเฉพาะสิ่งที่จำเป็น และทำให้ดีที่สุดเท่าที่เป็นไปได้ภายในขอบเขตนั้น
- แทนที่จะใช้เวลาคาดเดาฟีเจอร์ที่อาจจำเป็นในอนาคต ทีมจะ implement สิ่งที่จำเป็นจริง ๆ ด้วยเจตนาและความใส่ใจ
- เกณฑ์ความสมบูรณ์แตกต่างกันตามเลเยอร์ที่โค้ดอยู่
- เลเยอร์ที่ทั้งแอปพึ่งพา เช่น GPUI ต้องมีความสมบูรณ์สูง
- โครงสร้างข้อมูลอย่าง SumTree ที่ใช้ทั่ว codebase และสำคัญต่อประสิทธิภาพก็ต้องจัดการอย่างระมัดระวัง
- การปรับปรุงประสิทธิภาพเฉพาะจุดบริเวณขอบ ๆ จะทำในระดับที่บรรลุเป้าหมาย มากกว่าขัดเกลาเกินจำเป็น
- SumTree ใช้ random test เพื่อตรวจ edge case
- ความสมบูรณ์แบบนิยมไม่ควรขัดขวางการเรียนรู้ และเมื่อได้ดูแลโค้ดที่สร้างเองมาเป็นเวลานาน ผ่านการประนีประนอมต่าง ๆ แล้วกลับมาเขียนใหม่ ก็จะมีเหตุผลสำหรับการ rewrite ที่สะท้อนสิ่งที่เรียนรู้มา
บทเรียนจาก CRDT และโครงสร้าง buffer
- buffer ช่วงแรกของ Atom คือ array ของ string ใน JavaScript หรือก็คือ array ของบรรทัด
- buffer ของ Zed เป็น copy-on-write B-tree ที่เป็นมิตรต่อมัลติเธรดและทำ snapshot ได้ พร้อม index รายการหลายชนิดที่จำเป็น
- CRDT ไม่ใช่ตัวเลือกที่ชัดเจนตั้งแต่แรก และผ่านช่วงวิจัยที่อ่าน paper หลายฉบับก่อนจะสรุปเป็นแนวทางปัจจุบัน
- implementation ของ CRDT ถูกเขียนใหม่สองสามครั้ง แต่แนวทางโดยรวมยังคงรักษาไว้เป็นส่วนใหญ่
- สำหรับ Atom ซึ่งเป็น code editor ตัวแรก ทีมใช้แนวทาง “worse is better” ที่เร็วกว่าและหยาบกว่า และประสบการณ์นั้นช่วยให้รู้ว่าจุดเจ็บปวดจริงอยู่ตรงไหน
- หากเริ่มใหม่อีกครั้ง จะไม่ทำ buffer เป็นเพียง array ของบรรทัด และกรณีที่เคยช้ากับ edge case ในอดีตก็บังคับให้ต้องออกแบบให้มากขึ้น
เลเยอร์ที่ Zed ทุ่มเทเป็นพิเศษ
- GPUI เป็นพื้นที่ที่มุ่งความสมบูรณ์สูง เพราะเขียนใหม่ทั้งระบบ
editorcrate มีหลายเลเยอร์ที่แปลงข้อความ buffer ดิบให้เป็นบรรทัดบนหน้าจอ- การขยาย tab
- soft wrapping
- การแทรก block decoration
- การจัดการ fold
- เลเยอร์แปลงเหล่านี้มีกลยุทธ์ทดสอบที่สอดคล้องกันโดยใช้ property-based random test
- multi-buffer เป็นโครงสร้างที่นำบางส่วนของ buffer ต่าง ๆ มาร้อยเข้าด้วยกันเป็นหนึ่งเดียว และถือเป็นส่วนหลักเช่นกัน
- ในปี 2021 เคยใช้เวลาหลายวันเต็ม ๆ ไปกับการย่อ edge case ที่ random test พบและ debug
- หากเลเยอร์เหล่านี้ที่เขียนด้วย Rust ผิดพลาด ผลลัพธ์ไม่ใช่แค่มี stack trace โผล่ที่มุมเอดิเตอร์ แต่โปรแกรมอาจจบลงด้วย panic จึงต้องให้ความสำคัญกับความถูกต้อง
- มีการหารือเรื่องการปรับปรุง input และ loading ให้เป็นมิตรต่อ streaming มากขึ้น เพื่อลดสถานการณ์ที่ผู้ใช้ไม่ได้รับ feedback ใด ๆ เมื่อเปิดไฟล์ขนาดใหญ่ และ optimization ที่เกี่ยวข้องจะเข้า preview
ความแตกต่างที่เหลือถึงผู้ใช้และผู้ร่วมพัฒนา
- ผู้ใช้ปลายทางสุดท้ายแล้วอาจมองเป็นหลักว่าเอดิเตอร์เร็วหรือไม่
- สำหรับ developer tool และเอดิเตอร์ ผู้ใช้มีโอกาสร่วม contribute เข้าสู่ codebase ด้วยตัวเองสูง ดังนั้นภาษา implementation และวิธี build จึงมีผลต่อความเป็นไปได้ในการ contribute
- หาก Zed เขียนด้วย C++ จำนวนผู้ใช้ที่อยากแก้ไขเองอาจน้อยลง
- Rust และ
cargoทำให้ build โปรเจกต์และลองแก้ไขได้ง่ายขึ้น และลดความจำเป็นในการเรียนรู้ CMake หรือ Gyp - ความเข้มงวดของ Rust compiler ช่วยเพิ่ม ความเชื่อมั่นในการ merge จากมุมมองของการรับ contribution ภายนอก
- Zed ต้องการรักษา frame ให้อยู่ ต่ำกว่า 3ms และข้อกำหนดด้านประสิทธิภาพนี้ทำให้เลือก UI framework ที่เร่งด้วย GPU แทน CPU rasterizing
- แม้จะสนใจ Zig ด้วย แต่โครงสร้างภาษาเดียวที่ทั้ง server และ frontend เป็น Rust ก็มีข้อดี
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
เฟรมเวิร์ก UI แบบกำหนดเองของ Zed ตอนนี้อาจดูน่าสนุก แต่พอถึงจุดที่ตระหนักว่าต้องทำ accessibility สถานการณ์น่าจะเปลี่ยนไป
การทำ accessibility ในเฟรมเวิร์กแบบกำหนดเองโดยไม่สละประสิทธิภาพ ต้องทำงานจุกจิกเฉพาะแพลตฟอร์มจำนวนมาก และ Zed วางตำแหน่งตัวเองไม่ใช่แค่ editor ที่ไม่ใช้ก็ได้ แต่เป็น เครื่องมือสำหรับการทำงานร่วมกัน ดังนั้นจึงจำเป็นต้องทำให้ developer ทุกคนในทีมใช้งานได้
ในฐานะผู้ใช้ screen reader ผม/ฉันเบื่อเครื่องมือ “สมัยใหม่” ที่เขียนด้วย Rust ซึ่ง VoiceOver มองเห็นแค่หน้าต่างว่าง ๆ แล้ว เมื่อเทียบกับเว็บแอปที่แค่ติด aria label ให้ปุ่มไม่กี่ตัวและจัดการ focus ให้เรียบร้อย UI แบบกำหนดเองที่ต้องเปิดเผย control ทุกตัวให้ทุก OS เห็นนั้นยากกว่ามาก
โชคดีที่มี AccessKit อย่าง https://accesskit.dev/ เกิดขึ้นมา อาจช่วยให้งานง่ายขึ้นได้บ้าง แต่ไม่แน่ใจว่าเหมาะกับแอปขนาดใหญ่อย่าง editor แค่ไหน
เพราะสร้าง GPUI ขึ้นมาตั้งแต่ต้น จึงไม่สามารถใช้ฟีเจอร์ accessibility ที่แอปบน Swift หรือเว็บมีอยู่แล้วได้โดยตรง และบอกว่าจำเป็นต้องทำงานฝั่ง Zed ควบคู่กับการขยายความสามารถของ GPUI
แต่ลิงก์ที่ใส่ไว้สำหรับการคุยเรื่อง accessibility คือ https://github.com/zed-industries/zed/pull/1297 ซึ่งเป็น GitHub issue เกี่ยวกับปุ่มย้อนกลับ/ไปข้างหน้า จึงไม่มีประโยชน์ น่าจะตั้งใจลิงก์ไปที่ https://github.com/zed-industries/zed/discussions/6576 มากกว่า
เอกสารที่เกี่ยวข้อง: https://zed.dev/docs/themes
ดูเหมือนจะคิดเรื่อง accessibility ไว้แล้ว แต่ยังไม่ถึงขั้นนำไปใช้งานจริง
จนเมื่อไม่นานมานี้ก็มีเพียง binding ของเฟรมเวิร์ก C ที่มีอยู่เดิม หรือไลบรารี GUI ระดับ proof of concept เท่านั้น ต่อไปคงดีขึ้น แต่ก็เข้าใจความหงุดหงิดของคนที่ต้องพึ่งพาฟีเจอร์ accessibility
อย่างไรก็ตาม หลายโปรเจกต์มีแนวโน้มว่าจะสร้างไลบรารี GUI ให้แข็งแรงก่อน แล้วค่อยเพิ่มฟีเจอร์ accessibility ตามมา
startup จำนวนมากล้มเหลวเพราะทุ่มทรัพยากรให้ฟีเจอร์แวววาวที่ไม่ใช่จุดต่างของตัวเอง
ผลิตภัณฑ์ที่ประสบความสำเร็จด้วย UI ที่ไม่ใช่ native โดยมากใช้เทคโนโลยีเว็บหรือเฟรมเวิร์กที่โตเต็มที่อย่าง Qt ไม่ก็เป็นข้อยกเว้นอย่าง Blender ที่มีอายุ 30 ปี Apple เองก็เคยทำสิ่งคล้ายกันกับ iTunes แต่ iTunes บน Windows เป็นประสบการณ์ที่ไม่น่าอภิรมย์ เพียงแต่ผู้คนก็ยังใช้ iTunes อยู่ดี
เข้าใจเสน่ห์ของการอยากสร้างเฟรมเวิร์กอย่าง GPUI แต่ในบทความไม่ได้อธิบายว่าสิ่งนี้เกี่ยวข้องกับปัญหาที่ Zed ต้องการแก้อย่างไร
หมายถึงเครื่องมือที่ดูแค่ pixel แล้วเข้าใจเหมือนมนุษย์ และ parse ข้อความด้วย OCR อะไรทำนองนั้น
เข้าใจว่าเทคโนโลยีอย่าง VoiceOver รู้และใช้ประโยชน์จากนิยามหน้าต่างจริงกับองค์ประกอบต่าง ๆ ในระดับโปรแกรม
สำหรับโปรเจกต์ที่ต้องการความเร็วของการเรนเดอร์ด้วย GPU จน VoiceOver เห็นเป็น “หน้าต่างว่าง” วิธีแบบนี้อาจเป็นทางเลือกขั้นต่ำได้หรือเปล่า
ถ้าอย่างนั้นก็สงสัยด้วยว่าเนื้อหาทั้งหมดที่เรนเดอร์ด้วย GPU อย่างเกม จะหมายความว่าเข้าถึงไม่ได้ทั้งหมดหรือไม่
ผม/ฉันทำ Apple Shortcut ชื่อ “GPT Explains” ไว้บน iPhone โดยแตะสองครั้งที่ด้านหลังเครื่องเพื่อจับภาพหน้าจอ ส่งไปให้ OpenAI แล้วให้ส่งคำอธิบายสิ่งที่เห็น, แปลข้อความที่ไม่ใช่ภาษาอังกฤษเป็นอังกฤษ, โต้แย้งข้อกล่าวอ้างในมีม ฯลฯ กลับมา
สำเนาที่ตัด API key ออกแล้วอยู่ที่นี่: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
ฝากไว้เป็นการบอกว่า ก่อนจะขึ้นขบวนกระแส text editor ตัวใหม่ ลองอ่าน ไลเซนส์ ที่ผู้ใช้ต้องยอมรับสักครั้ง
“Customer Data ซึ่งประกอบด้วยเนื้อหาของผู้ใช้ที่สร้างขึ้นระหว่างการใช้ Solution จะถูกจัดประเภทเป็น User Content. User Content จะถูกส่งออกจากสภาพแวดล้อมของผู้ใช้ก็ต่อเมื่อเลือกแชร์โปรเจกต์ใน Editor เพื่อทำงานร่วมกับผู้ใช้ Zed คนอื่นเท่านั้น”
“[...] การเข้าถึง User Content ดังกล่าวของ Zed จะจำกัดไว้เพื่อการดีบักและปรับปรุง Solution”
จะไม่อธิบายเพิ่ม ดังนั้นแต่ละคนสรุปกันเอาเอง
ถ้าเลือกแชร์โปรเจกต์กับคนอื่นเพื่อทำงานร่วมกัน ก็เป็นเรื่องปกติที่เนื้อหาโปรเจกต์นั้นจะถูกส่งออกจากเครื่องของตัวเอง ไม่อย่างนั้นมันจะทำงานได้อย่างไร?
เพราะบทความนี้เลยลองใช้ Zed ดู และก็ดูมีแววพอสมควร แต่ใช้ไม่ได้เพราะไม่รองรับ remote host/devcontainer
ฟีเจอร์นี้ของ VSCode เป็นแกนหลักของเวิร์กโฟลว์ผมเลย จริง ๆ แล้วผมไม่อยากพัฒนาบน Mac แต่อยากใช้ Mac เหมือนเป็นพอร์ทัลเข้าไปยัง VM และคอนเทนเนอร์ที่ผมใช้เขียนโค้ด
มันช่วยแยกโปรเจกต์ออกจากกันได้มาก และยังดีขึ้นในแง่ความปลอดภัยเพราะไม่ต้องวางสภาพแวดล้อมพัฒนาหรือ dependency ไว้บนเครื่องโฮสต์จริง
อยากรู้ว่าข้อดีของ remote host/devcontainer ใน VSCode เมื่อเทียบกับเซสชันรีโมตทั่วไปคืออะไร
เป็นบทสัมภาษณ์ที่ยอดเยี่ยม แนะนำอย่างยิ่ง เพราะช่วยให้เห็นกรอบคิดของนักพัฒนาว่ามองการพัฒนาจากหลายมุมอย่างไร
แต่มีจุดหนึ่งที่เห็นต่าง
ไม่ใช่ว่า “ชื่อที่เหมาะที่สุดสำหรับเท็กซ์เอดิเตอร์ที่สร้างด้วย Zig ถูก Zed เอาไปแล้ว” แต่ชื่อนั้นคือ “Zag” ต่างหาก ;)
zedมีedอยู่edคือ line editor ตระกูล Unix ที่เป็นบรรพบุรุษของex,vi,edlinและยังคงมีอยู่จนถึงทุกวันนี้https://en.wikipedia.org/wiki/Ed_(text_editor)
ส่วน
agหรือ the silver searcher ก็ยอดเยี่ยมเหมือนกัน แต่ผมมองว่า Zed ใกล้กับการแก้ไขโค้ดมากกว่าการค้นหาโค้ดhttps://geoff.greer.fm/ag/
ผมไม่ได้ใช้ Zed แต่เคยเห็น José Valim ใช้ตอน live coding ปกติผมใช้ VSCode เป็นหลัก แต่มีฟีเจอร์หนึ่งที่เห็นใน Zed แล้วค่อนข้างน่าสนใจ
เวลาใช้ “Find All” มันจะแสดงชิ้นส่วนของไฟล์ทั้งหมดที่ตรงกันในพาเนลผลลัพธ์เหมือน VSCode แต่ตรงนั้นสามารถ แก้ไขชิ้นส่วนผลการค้นหาได้โดยตรง และยังใช้ฟีเจอร์แก้ไขทั่วไปอย่าง multi-cursor ได้ตามปกติ
ใน VSCode ต้องคลิกผลการค้นหาเพื่อเปิดไฟล์แล้วค่อยแก้ตรงนั้น เลยรู้สึกว่าเป็นฟีเจอร์ที่เจ๋งและน่าประทับใจมาก แม้จะยังไม่ถึงขั้นทำให้ย้ายไปใช้ แต่ก็จะนึกถึงเป็นครั้งคราวทุกครั้งที่ VSCode ทำให้หงุดหงิด
occurและmulti-occurมาตั้งแต่ยุค 80 และทำงานแบบนี้ได้ ยอดเยี่ยมจริง ๆช่วงหลัง ๆ อินเทอร์เฟซของเครื่องมืออย่าง ripgrep ก็มี โหมดที่แก้ไขได้ ด้วย จึงสะดวกมากสำหรับการรีแฟกเตอร์ แน่นอนว่าชื่อไฟล์ก็แก้แบบเป็นชุดได้เช่นกัน
https://www.masteringemacs.org/article/searching-buffers-occ...
https://rgel.readthedocs.io/en/latest/
https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
อาจฟังดูไร้สาระ แต่หนึ่งในเหตุผลหลักที่ใช้ JetBrains แทน VSCode คือสามารถค้นหาไดเรกทอรีแล้วเปิดจากพาเนลนำทางได้
พอเห็นคอมเมนต์นี้ถึงนึกขึ้นได้ว่าลืมมันไปแล้ว คงต้องลองกลับไปใช้อีกครั้ง
https://marketplace.visualstudio.com/items?itemName=jakearl....
หนึ่งในทริกที่ผมชอบคือแก้ด้วย multi-cursor แล้วใช้ชอร์ตคัตไปท้ายบรรทัดหรือไปคำถัดไปเพื่อแก้ไขจำนวนมาก
ถ้าทำแบบนั้นข้ามหลายไฟล์ได้ก็คงดี
ใช้ไม่ได้บน Windows หรือ Linux ถ้ารองรับเมื่อไหร่ก็ช่วยบอกอีกที
เป็นบทสัมภาษณ์ที่ยอดเยี่ยม
ชอบที่คิดอย่างลึกซึ้งว่าจะ ขัดเกลาอะไรให้มากเป็นพิเศษ งานที่ดีที่สุดของผมก็มักออกมาตอนรอบที่สอง สาม หรือสี่เหมือนกัน
อยากรู้ว่ามีแผนอย่างไรกับความสามารถในการจัดการการตั้งค่าด้วยสคริปต์ ผมยังไม่ได้ใช้ Zed มากนัก ตอนนี้ทำได้หรือยัง? อะไรอย่าง Neon จะช่วยเชื่อมช่องว่างระหว่าง VSCode กับผู้ใช้ Atom เดิมได้ไหม?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
การดู v2 น่าสนใจเสมอ ผมเคยเห็นทั้งกรณีที่กลายเป็นหายนะเพราะฟีเจอร์ล้น และกรณีที่ยอดเยี่ยมเพราะกระชับและคล่องตัวขึ้น
ทุกวันนี้ในวงการเว็บแอปมีเครื่องมือมากมายจนสงสัยว่าความเสี่ยงนี้ไม่ได้ใช้กับแค่ v2 แต่ใช้กับ v1 เหมือนกันหรือไม่ ช่วงนี้เห็น v1 ที่บวมอย่างน่าตกใจอยู่บ่อย ๆ และหลายครั้งต้องตั้งใจมองหาเครื่องมือที่ทำให้น้อยลง
ได้ลองใช้ Zed แล้ว และรู้สึกคล้ายกับ VSCode รู้ว่ามี ฟีเจอร์มัลติเพลเยอร์ ที่ดีกว่า Live Share แต่เมื่อดูจากภายนอกแล้วยังต้องมีเหตุผลโน้มน้าวใจมากกว่านี้ให้ย้ายไปใช้
ถ้า Zed สามารถแทน Xcode ได้ ก็น่าจะอยากลองใช้ต่อมากขึ้น ตั้งแต่การลบ derived data หรือเคลียร์ build folder ไปจนถึงแครชแบบสุ่ม การใช้ Xcode เป็นเรื่องทรมาน
เมื่อเทียบกับประสบการณ์นักพัฒนาของ Android Studio แล้วต่างกันลิบลับ ในการพัฒนา iOS ก็อยากได้ประสบการณ์แบบ Android Studio มาตลอด
ชอบแอปเนทีฟมากจริง ๆ แต่ตอนนี้ถูกผูกไว้กับ VS Code เห็นว่าแค่เคอร์เซอร์กะพริบใน VS Code ก็ใช้พลังงานมากแล้วรู้สึกเจ็บใจ
เคยลองใช้ Zed อยู่พักหนึ่ง แต่ปรับให้เข้ากับเวิร์กโฟลว์ของตัวเองไม่ได้ ชอบตรงที่เบาและเร็ว โปรเซสของ VS Code ใช้ราว 3GB ส่วน Zed ใช้ 300MB ดังนั้น หน่วยความจำหนึ่งในสิบ จึงเป็นความต่างที่มีความหมาย
แต่จำเป็นต้องใช้การรองรับ Jupyter Notebook ที่ VS Code มีให้ และคุ้นเคยเกินไปกับการพัฒนาแบบรีโมตจาก Mac ไปยังเครื่อง Ubuntu แล้ว VS Code ทำเรื่องนี้ได้ดีมาก
หวังว่า Zed จะอยู่ได้นานพอจนรองรับเวิร์กโฟลว์ของฉันได้
บางทีทุกคนอาจเปิดส่วนขยายไว้มากกว่าก็ได้
ตาม Lindy effect https://en.wikipedia.org/wiki/Lindy_effect ก็น่าจะต้องรออีกสักปีถึงจะได้เห็นอะไรบางอย่าง
ดูหน้า About แล้ว ฟีเจอร์ไลฟ์โค้ดดิ้ง ดูมีประโยชน์ นักพัฒนาก็น่าจะตื่นเต้นกัน เพราะเป็นโปรเจกต์ที่สนุก ได้เขียนอัลกอริทึม ปรับประสิทธิภาพ และทำ GPU programming ด้วย
แต่ก็สงสัยว่าใครต้องการเท็กซ์เอดิเตอร์อีกตัวที่คงไม่มีวันเทียบเท่าฟีเจอร์ของ Vim กับ terminal multiplexer ได้
VS Code เพิ่งโผล่มาอย่างกะทันหันเมื่อไม่นานมานี้และมีคนใช้จำนวนมาก จึงแสดงให้เห็นว่าหลังยุค Vim ก็ยังมีโอกาสสำหรับเอดิเตอร์ใหม่
ต้องรอดูว่า Zed จะได้แรงส่งพอที่จะรองรับความต้องการแบบ long tail ของนักพัฒนาคนอื่น ๆ หรือไม่ แต่การมีผลิตภัณฑ์ออกมาแข่งขันเพื่อดึงผู้ใช้มากขึ้นก็น่าคาดหวังทีเดียว
ไม่ต้องเลียนแบบ Vim ก็สามารถใช้ Neovim และปลั๊กอินทั้งหมดได้ตามเดิม
ยังเสียดายที่ JetBrains ยังคงดูแลปลั๊กอินเลียนแบบ Vim ที่ผู้ใช้ Vim เรียกว่าห่วยอยู่ ถ้าใน IDE ทำฟรอนต์เอนด์ Neovim แบบเนทีฟ ก็จะมีจุดแข็งที่ทรงพลังกว่ามากว่า “รองรับ Neovim และระบบนิเวศของมันอย่างสมบูรณ์” แต่ตอนนี้ยังหยุดอยู่แค่ “มีปลั๊กอินคล้าย Vim”
ใช้เครื่องมือที่ชอบและช่วยให้งานเสร็จก็พอ ซึ่งรวมถึง Vim ด้วย แต่เบื่อกับการทำเหมือนว่าการใช้ Vim เป็นพรอันประเมินค่าไม่ได้ที่ไม่มีอะไรทดแทนได้
การเป็นคนคิดได้ดีขึ้นช่วยเพิ่มประสิทธิภาพในฐานะโปรแกรมเมอร์แบบก้าวกระโดดมากกว่าเครื่องมือใด ๆ
มีเอดิเตอร์ที่ฟีเจอร์ค่อนข้างครบและผู้คนพอใจ หรืออย่างน้อยก็คุ้นเคยกันอยู่แล้ว เอดิเตอร์ใหม่จะหาที่อยู่ตรงไหนได้?
“มัลติเพลเยอร์” นั้นเจ๋ง แต่ค่อนข้างเป็น edge case
โมเดลธุรกิจก็ยังไม่มั่นใจ ผู้คนต้องการให้ channel, call, chat รวมอยู่ในโค้ดเอดิเตอร์จริงหรือ? ส่วนตัวแทบจะรู้สึกต่อต้านโดยสัญชาตญาณ แต่อาจเป็นแค่ฉันก็ได้