บทสัมภาษณ์ Mitchell Hashimoto: Ghostty, Zig และการดูแลโอเพนซอร์ส

• Mitchell Hashimoto สร้าง Ghostty และ Vouch ต่อจาก Vagrant, Terraform และ Vault พร้อมสรุปมาตรฐานของตัวเองเกี่ยวกับเทอร์มินัล, Zig, การดูแลโอเพนซอร์ส และคุณภาพผลิตภัณฑ์
• Ghostty เริ่มต้นจากโปรเจ็กต์ส่วนตัวเพื่อเรียนรู้การเขียนโปรแกรม GPU, การเขียนโปรแกรมระบบเดสก์ท็อป/โหนดเดี่ยว และ Zig ก่อนจะพัฒนาไปสู่การเป็นเทอร์มินัลเนทีฟข้ามแพลตฟอร์มที่เร็วและมีฟีเจอร์ครบ
• เทอร์มินัลไม่ควรพยายามยัดทุกอย่างไว้แบบเบราว์เซอร์ แต่ควรรักษา ความสามารถในการประกอบใช้งาน ของแอปแบบข้อความ, ระบบอัตโนมัติ และโมเดลความปลอดภัยที่ชัดเจนไว้ โดยข้อจำกัดของ PTY ในฐานะสตรีมไบต์ที่ไม่มีโครงสร้างยังคงเป็นปัญหาอยู่
• เขามองว่าผู้ดูแลโอเพนซอร์สไม่มีภาระผูกพันต่อผู้ใช้ แต่ถ้าจะสร้างซอฟต์แวร์ที่ดี ก็ควรแก้หลายปัญหาผ่าน ฟีเจอร์ที่สอดคล้องกันหนึ่งเดียว มากกว่ารับทุกคำขอแบบตรงตัว
• แม้การเปลี่ยนแปลงใหญ่ของ Zig จะสร้างภาระให้ downstream แต่ก็ช่วยยกระดับคุณภาพของ API และเครื่องมือคอมไพล์ และเขาประเมินว่า AI สามารถลดงานซ้ำซ้อนจากการเปลี่ยนแปลงขนาดใหญ่ จึงช่วยลด ภาระด้านความเข้ากันได้ย้อนหลัง ได้

---

เหตุผลที่ Ghostty เริ่มต้นขึ้น

• Mitchell Hashimoto หลังจากสร้าง Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint ก็ได้มาสร้าง Ghostty และ Vouch ในปัจจุบัน
• Ghostty เริ่มจากการตระหนักว่า แม้เขาจะสร้างแอปพลิเคชัน CLI มาราว 15 ปี แต่กลับยังไม่เข้าใจอย่างแท้จริงว่า terminal emulator ทำงานอย่างไร
• หลังออกจาก Hashicorp มีอยู่ 3 ด้านที่เขาอยากกลับไปแตะอีกครั้ง
  • การเขียนโปรแกรม GPU ในบริบทก่อนยุค AI
  • การเขียนโปรแกรมระบบเดสก์ท็อป/โหนดเดี่ยวที่แตกต่างจากระบบกระจาย
  • การใช้ Zig
• เป้าหมายแรกเริ่มคือให้มันรัน vim กับคอมไพเลอร์ได้ สร้าง Ghostty ด้วยตัวเองได้ แล้วค่อยทิ้งมันไป
• แต่เมื่อสำรวจระบบนิเวศของเทอร์มินัลมากขึ้น เขามองว่ายังขาดเครื่องมือที่เร็ว มีฟีเจอร์ครบ และเป็นเนทีฟข้ามแพลตฟอร์ม
• หลังแชร์ให้เพื่อนใน Discord ใช้ ก็เริ่มมีคนที่ใช้มันทุกวัน และ Ghostty Discord ก็เดิมทีคือห้องแชตกลุ่มเพื่อนที่เปลี่ยนมาเป็นพื้นที่เฉพาะ
• เขามองว่าการเป็นที่รู้จักต่อสาธารณะอาจดึงความสนใจมากเกินไป จึงเปิดให้ใช้งานแบบ เบตาแบบปิด อยู่เป็นเวลานาน

เทอร์มินัลควรขยายไปได้แค่ไหน

• Hashimoto ไม่เห็นด้วยกับแนวทางที่ผลักเทอร์มินัลให้กลายเป็นแพลตฟอร์มแอปพลิเคชันขนาดใหญ่แบบไร้ขอบเขต
• เทอร์มินัลอาจจะรองรับทั้งวิดีโอ การเข้าถึงไมโครโฟน หรือเลย์เอาต์แบบ responsive ได้เหมือนเบราว์เซอร์หรือ Java runtime ในอดีต แต่เขามองว่าเบราว์เซอร์ เดสก์ท็อป และแอปแบบข้อความบนกริดตัวอักษรคงที่ ต่างก็มีสิ่งที่ตัวเองทำได้ดีที่สุดคนละแบบ
• แอปพลิเคชันแบบข้อความทำได้เร็ว โต้ตอบได้ง่าย และควรมี โมเดลความปลอดภัย ที่ชัดเจน
• จุดแข็งของแอปบนเทอร์มินัลอยู่ที่ความสามารถในการประกอบใช้งาน
  • TUI มีคุณสมบัตินี้น้อยกว่า แต่เครื่องมือ CLI ส่วนใหญ่ก็มีกลไกที่ทำให้ใช้งานเหมือนฟังก์ชันได้ นอกเหนือจาก stdin/stdout
  • ปรัชญาแบบ UNIX ที่ว่า “ทำสิ่งเดียวให้ดี” คือรูปแบบสุดขั้วของแนวคิดนี้
  • Neovim และเครื่องมือ AI ต่างก็มี command-line flag เพิ่มขึ้นเรื่อย ๆ
• แอปเทอร์มินัลที่ดีขึ้นย่อมนำไปสู่ ระบบอัตโนมัติ และความสามารถในการเขียนสคริปต์ที่ดีขึ้น
• สัญญาณ in-band ของ PTY หรือก็คือสตรีมไบต์ที่ไม่มีโครงสร้างรวมถึง escape sequence ยังเป็นปัญหาใหญ่
• ระบบนิเวศของ Nushell พยายามแก้สิ่งนี้ในอีกชั้นหนึ่ง แต่ Hashimoto มองว่าจำเป็นต้องมีการปรับปรุงที่ลึกกว่านั้น
• แม้หลายคนจะไม่ชอบระบบนิเวศของ Microsoft แต่เขามองว่า PowerShell ทำหลายอย่างได้ถูกต้องมากในด้าน structured data

แนวคิด API เทอร์มินัลแบบไม่ยึดติดกับของเดิม

• เมื่อนึกถึง API เทอร์มินัลแบบใหม่ Hashimoto จะอ้างอิงเฟรมเวิร์กของแพลตฟอร์มแอปขนาดใหญ่อย่างเบราว์เซอร์, Emacs, Apple, Microsoft, Android และเกมคอนโซล
• เขามองว่าควรสำรวจแบบอย่างที่สั่งสมมาแล้วก่อน เช่น DOM และ JS API บนเว็บ, AppKit, Cocoa, SwiftUI ของ Apple, Win32 และ WinUI ของ Windows, GTK และ Qt บน Linux
• แค่เรื่องการเข้าถึงคลิปบอร์ดก็เห็นความต่างแล้ว เพราะโปรโตคอลเทอร์มินัลแบบดั้งเดิมเน้นข้อความ แต่เดสก์ท็อปรองรับรูปภาพและ MIME type หลากหลายมานาน ดังนั้นจึงต้องไปดูเอกสารคลิปบอร์ดของแต่ละแพลตฟอร์ม
• เขายังไม่ได้เพิ่ม custom protocol เข้าไปใน Ghostty

• n-screen API

  • ปัจจุบันเทอร์มินัลทั่วไปมักมีสองหน้าจอคือ main screen และ alt screen
  • main screen ใกล้เคียงกับเชลล์และ scrollback ส่วน alternate screen ใกล้กับ Neovim และ TUI ส่วนใหญ่
  • โครงสร้างนี้เป็นการเปิดหรือปิดโหมดอย่างใดอย่างหนึ่ง และมักกินพื้นที่เต็มจอพร้อมทำให้สูญเสีย scrollback
  • Hashimoto กำลังคิดถึง n-screen API ที่สามารถสร้างและเติมข้อมูลลงในหน้าจอพื้นหลังได้ไม่จำกัด
  • แต่ละหน้าจออาจมีขนาดกริดต่างกันและซ้อนทับกันได้ โดย terminal emulator จะจัดการเรื่องการตัดบรรทัด การเลือกข้อความ และการ route อีเวนต์เมาส์
  • หากกำหนดให้บางหน้าจอเป็นหน้าต่างอิสระ terminal emulator ก็อาจเรนเดอร์มันนอกกริดได้
  • ตัวอย่างที่เขายกคือการเปิดแท็บของ Neovim พร้อมกันหลายแท็บในลักษณะคล้ายแท็บหน้าต่างเนทีฟ

• โปรโตคอลปุ่ม

  • โปรโตคอลเมาส์ในปัจจุบันรับอีเวนต์ได้เฉพาะเวลาผู้ใช้คลิกที่เซลล์กริดของหน้าจอปัจจุบัน
  • รายการประวัติที่เข้าไปอยู่ใน scrollback จะไม่สามารถรับคลิกอีเวนต์ได้
  • ปัจจุบันเทอร์มินัลรองรับโปรโตคอลไฮเปอร์ลิงก์ OSC 8
  • Hashimoto กำลังคิดถึง button protocol ที่คล้าย OSC 8 แต่เมื่อคลิกแล้วจะส่งข้อความที่โปรแกรมกำหนดไว้
  • ตัวอย่างเช่น ปุ่มที่มี ID เป็น open_profile สามารถคงสถานะที่ลงทะเบียนไว้ได้ แม้ผู้ใช้จะเลื่อนกลับไปดูประวัติ
  • ฟีเจอร์นี้เกี่ยวข้องกับแอปบน main screen ที่มี scrollback และเชื่อมโยงกับปัญหาว่าในแอป main screen อย่าง Claude Code การเปิดไฟล์หรือลิงก์ภายในแอปจะไม่ทำงานเมื่อมันถูกเลื่อนเข้าไปอยู่ในประวัติ

การขาดมาตรฐานและการดูแลโอเพนซอร์ส

• Hashimoto เคยทดลองแทนที่โปรโตคอล PTY ทั้งหมดด้วย Wayland แต่ก็ยกเลิกไป
• เขามองว่าเทอร์มินัลอาจมองได้คล้าย windowing server ที่จัดการหน้าต่างและวิดเจ็ตบนหน้าต่าง และ Wayland ก็เป็นโปรโตคอลที่ดีสำหรับแก้ปัญหาเดสก์ท็อปโลคัลและการเรนเดอร์หน้าต่าง
• ปัญหาหนึ่งของเทอร์มินัลคือไม่มี องค์กรกำหนดมาตรฐาน อีกต่อไปแล้ว
• แม้จะยังมีสเปกเก่าเหลืออยู่ แต่การทำมาตรฐานในช่วง 20 ปีที่ผ่านมาเกิดขึ้นจากการดูว่าเทอร์มินัลที่ได้รับความนิยมมากที่สุดทำอะไร
• ผลลัพธ์คือฟีเจอร์ต่าง ๆ ถูกปะปนกันไปหมด และไม่มีผู้เล่นที่ผลักดันวิสัยทัศน์เฉพาะทางอย่างชัดเจน
• เขายังไม่ตัดสินใจเส้นทางในอนาคต และมองว่าอาจสร้างพื้นที่แอปแบบข้อความใหม่ที่ไม่ใช่เทอร์มินัล แล้ววาง translation layer สำหรับแอป legacy ไว้อีกชั้นหนึ่งก็ได้

• สมดุลระหว่างความต้องการของผู้ใช้กับวิสัยทัศน์ใหญ่

  • Hashimoto พูดต่อสาธารณะมาตลอดว่าผู้ดูแลโอเพนซอร์สมี ภาระผูกพันต่อผู้ใช้เป็นศูนย์
  • บรรทัดแรกของไลเซนส์โอเพนซอร์สคือ “as is, no warranty” และเขามองว่าผู้ใช้ได้รับซอฟต์แวร์ฟรีโดยไม่มีสิทธิ์เรียกร้องอะไรตอบแทน
  • ขณะเดียวกัน เขาก็รู้สึกรับผิดชอบที่อยากแก้ปัญหาและทำให้ซอฟต์แวร์ดีขึ้น เพราะต้องการสร้างซอฟต์แวร์ที่ดี
  • บางวันเขาดู issue แล้วแก้ปัญหาของคนอื่น บางวันก็ไม่ดู issue, discussion หรือ PR เลย แล้วโฟกัสกับสิ่งที่ตัวเองอยากทำ
  • หากมัวจัดการแต่ issue ของผู้ใช้ทุกวัน ซอฟต์แวร์ก็จะเสถียรแต่หยุดนิ่ง แต่ถ้ารับทุก PR มันก็อาจเปลี่ยนแปลงมากแต่สูญเสียวิสัยทัศน์
  • เขาบอกว่าการมีส่วนร่วมส่วนใหญ่เป็นเพียงการแก้ปัญหาเฉพาะของแต่ละคน และถ้ารับทั้งหมด โค้ดก็จะพอกพูนเป็นภูเขา
  • ในทางกลับกัน หากเข้าใจปัญหาอย่างลึกซึ้ง ก็สามารถแก้คำขอฟีเจอร์หลายอย่างด้วยระบบเดียวที่สวยงามได้พร้อมกัน
  • ใน วิดีโอการออกแบบฟีเจอร์ เขายกตัวอย่างกรณีที่ปิดคำขอฟีเจอร์แยกกัน 3-4 รายการ แล้วแก้ทั้งหมดพร้อมอีกหนึ่งปัญหาด้วยฟีเจอร์เดียว

• ความต่างระหว่างฟีเจอร์ครบกับความเทอะทะ

  • ฟีเจอร์ค้นหา ซึ่งเป็นหนึ่งในความต้องการมากที่สุดของ Ghostty ถูกพัฒนาและปล่อยใช้งานแล้ว
  • ผู้ใช้บางคนวิจารณ์ว่าการค้นหาทำลายความมินิมัลของ Ghostty และทำให้มันเทอะทะ แต่ Hashimoto ตอบว่าเขาโปรโมต Ghostty ในฐานะ เทอร์มินัลที่มีฟีเจอร์ครบ
  • เขาแยกความต่างระหว่างความครบเครื่องกับความบวมเกินจำเป็น
  • ฟีเจอร์ค้นหาใช้พื้นที่ดิสก์และมีภาระโหลด RAM แต่ถูกออกแบบให้ถ้าไม่ใช้ ก็จะไม่มีโค้ดใดถูกรัน
  • ดังนั้นสำหรับผู้ใช้ที่ไม่ใช้ฟีเจอร์นี้ เขามองว่ามันแทบไม่มีต้นทุนขณะรัน
  • Ghostty มุ่งเป็นเทอร์มินัลที่ผู้ใช้ปรับแต่งให้ตรงความต้องการได้ ใช้งานได้ตั้งแต่ค่าเริ่มต้น และซ่อนฟีเจอร์ไว้จนกว่าจะจำเป็นหรือผู้ใช้เริ่มค้นหา
  • สำหรับคำขอให้คง flag สำหรับตัดฟีเจอร์ออก เขามองว่าการให้ผู้ดูแลรักษา flag นั้นต่อ กับการให้ผู้ใช้ดูแล fork ที่ตัดฟีเจอร์ออกเอง เป็นภาระประเภทเดียวกัน

สิทธิของโอเพนซอร์ส การเปลี่ยนแปลงของ Zig และคุณภาพของ API

• Hashimoto เชื่อว่าควรมีทั้ง personal fork และ maintained fork มากกว่านี้อีกมาก
• เขามองว่าโอเพนซอร์สที่ขับเคลื่อนด้วยเงินลงทุนแบบ venture สร้างคนรุ่นหนึ่งที่คาดหวังโปรเจ็กต์ที่ขัดเกลาอย่างดี มีเว็บไซต์ ทีมซัพพอร์ตแบบเสียเงิน และการช่วยเหลือผ่าน Slack หรือ Discord
• แต่แก่นแท้ของโอเพนซอร์สไม่ใช่การรับประกันผลิตภัณฑ์ แต่คือ อิสรภาพและสิทธิ
  • ใช้ได้ตามต้องการ
  • แก้ไขได้
  • fork ได้
• ความเสถียรหรือภาระในการดูแลรักษาไม่ใช่ส่วนหนึ่งของสิทธิเหล่านั้น
• เขาบอกว่าไม่อาจโทษผู้ดูแลฝ่ายเดียวสำหรับคอมมิตที่มีช่องโหว่ด้านความปลอดภัย เพราะผู้ใช้เองก็มีความรับผิดชอบที่ไม่ได้ตรวจสอบคอมมิตนั้น
• หากต้องการหลักประกันที่เข้มแข็งกว่าและต้องการสิทธิ์ในการตำหนิใครสักคน ก็ควรจ่ายเงินซื้อซอฟต์แวร์แล้วสร้างความสัมพันธ์แบบ vendor-customer
• ในโปรเจ็กต์ส่วนตัว เขาอาจไม่ merge แม้แต่ PR ที่แก้บั๊กที่ตัวเองไม่เคยเจอ
  • เพราะการ merge คือคำมั่นว่าจะดูแลโค้ดนั้นไปตลอด

• มุมมองต่อ Zig

  • Hashimoto รู้ตั้งแต่แรกว่าการเลือก Zig ต้องแลกกับอะไร และเมื่อได้แก้แพตช์คอมไพเลอร์ เขาก็เข้าใจชุมชน วัฒนธรรม และปรัชญาของมันมากขึ้น
  • การเปลี่ยนแปลงด้าน I/O ที่ยังไม่เริ่มต้นนั้น เขาคาดว่าจะเป็นหนึ่งในงานที่ยากที่สุดของ Zig
  • แม้ Zig จะได้รับความนิยมมากขึ้น แต่ Andrew ก็ไม่ถอยจากการเปลี่ยนแปลงที่เขาเห็นว่าจำเป็น และ Hashimoto ในฐานะผู้ใช้ downstream ก็มองว่านั่นเป็นเรื่องดี
  • Zig 0.15 เปลี่ยน writer interface จนกระทบโค้ดแทบทั้งหมดที่มีการเขียนเอาต์พุต แต่เขามองว่า API โดยรวมดีขึ้นมาก
  • Zig กำลังโฟกัสกับเครื่องมือคอมไพล์ และถึงขั้นตัดฟีเจอร์ของภาษาออกเพื่อเร่งความเร็วคอมไพล์
  • เขาบอกว่าสามารถ build เทอร์มินัลทั้ง lib-ghostty ได้ทันที แต่ Andrew ยังมองว่าเวลาเป็นระดับมิลลิวินาทีนั้นก็ยังช้าเกินไป
  • เขามองว่า Zig 1.0 จะมาถึงในสักวันหนึ่ง แต่ยังอีกหลายปี
  • AI สามารถลดความเจ็บปวดของ downstream จากการเปลี่ยนแปลงของภาษาได้
  • เขาบอกว่าเมื่อแสดงตัวอย่างวิธีแก้ในหลายบริบทแล้วปล่อยให้ระบบจัดการส่วนที่เหลือ งานใน diff ขนาดใหญ่ราว 90% ถูกทำให้โดยอัตโนมัติ
  • หากสามารถอธิบายวิธีเปลี่ยนจากสถานะ A ไปสู่สถานะ B ได้ ก็อาจบ่งชี้ถึงอนาคตที่ความหมายของ backward compatibility ลดความสำคัญลง
  • แม้จะย้อนแย้งกับนโยบายต่อต้าน AI ของ Zig แต่เขามองว่า AI ช่วยลดความเจ็บปวดที่การเปลี่ยนแปลงสร้างให้ผู้ใช้ downstream ได้

• ไลบรารีและการออกแบบ API

  • วิธีที่เป็นรูปธรรมที่สุดในการออกแบบไลบรารีที่ดี คือการลองใช้ไลบรารีจำนวนมากจากหลายชุมชนด้วยตัวเอง
  • การใช้ไลบรารีจากหลากหลายระบบนิเวศ เช่นเดียวกับการเรียนรู้ภาษาที่อาจไม่ได้ใช้จริงในงาน จะช่วยขยายมุมมอง
  • สมัยเรียนมหาวิทยาลัย เขาเคยทำโปรดักต์ของเล่นด้วย Prolog, Haskell, Clojure และ Java เพื่อเรียนรู้ระบบ build, การใช้งาน, ไลบรารี, เว็บเฟรมเวิร์ก, เว็บเซิร์ฟเวอร์ และแอปเซิร์ฟเวอร์ของแต่ละระบบนิเวศ
  • เขามองว่าวัฒนธรรมของแต่ละระบบนิเวศซึมอยู่ในวิธีแยก concern ของไลบรารีและเฟรมเวิร์ก รวมถึงรูปร่างของ API
  • เขายกตัวอย่างการย้ายแนวคิดว่าเคยลองนำ builder pattern ที่ใช้กันมานานใน Java ไปใช้ใน Ruby และพบว่ามันใช้ได้ดี
  • เขามองว่า Docker มีหลายองค์ประกอบด้านการ deploy และ runtime ปะปนเข้ามาใน flow การพัฒนา ขณะที่ Vagrant ตั้งใจใช้คำนาม, CLI และการตั้งค่าที่โฟกัสกับการพัฒนาโดยตรง

• ภาวะกลืนไม่เข้าคายไม่ออกของผู้สร้างเครื่องมือและเทคโนโลยีสแต็ก

  • Hashimoto บอกว่าตัวเองเป็นผู้สร้างเครื่องมือมาตลอดชีวิต และเชื่อใน ภาวะกลืนไม่เข้าคายไม่ออกของผู้สร้างเครื่องมือ
  • นั่นคือคุณเข้าใจปัญหาอย่างลึกซึ้งจนสร้างเครื่องมือในอุดมคติได้ แต่เมื่อมันได้รับความนิยม คุณอาจกลายเป็นผู้สร้างเครื่องมือที่หลุดจากการใช้งานจริง แทนที่จะเป็นผู้ใช้ตัวจริง
  • แม้เขาจะใช้เทอร์มินัลทุกวัน แต่กลับไม่ได้พัฒนา TUI มากพอ และยังพึ่งผู้ดูแลอย่าง rockorager ที่ดูแลอีเมลไคลเอนต์และ IRC client หลายตัว รวมถึงเขียนสเปกไว้ด้วย
  • สำหรับสแต็กเทคโนโลยีปัจจุบัน เขามีท่าทีประมาณว่า “ก็โอเค”
  • เขามองว่าชุมชน frontend, TypeScript และ React types มีข้อดีหลายอย่าง แต่การเปลี่ยนแปลงมีมากเกินไป ความซับซ้อนสูง และชั้นของ abstraction ไม่ชัดเจน
  • เขาบอกว่าหลายด้านมีความซับซ้อนเพิ่มขึ้นแบบไม่เป็นเชิงเส้น เหมือนการเปลี่ยนผ่านจาก HTTP/1 ไปสู่ HTTP/2 และ HTTP/3
  • เขามองว่าอุตสาหกรรมเคลื่อนไหวเร็วเกินไป กำลังทำให้สิ่งที่ควรเรียบง่ายกลายเป็นซับซ้อน และ AI กับเครื่องมือที่เกี่ยวข้องยิ่งเร่งแนวโน้มนี้

หลักการ วัฒนธรรม คุณภาพ และการเรียนรู้

• เขาบอกว่าเอกสารหลักการของ Hashicorp และแนวทางพัฒนา Ghostty สะท้อนตัวเขาเองทั้งหมด จึงทำให้ปฏิบัติตามได้ง่ายในทุกวัน
• หากตั้งหลักการที่ไม่ตรงกับตัวเอง ก็จะลงเอยเหมือนปณิธานปีใหม่ที่ยากจะทำจริง
• Ghostty ให้ความสำคัญทั้งแกนข้ามแพลตฟอร์มและ GUI แบบเนทีฟ
  • แกนหลักเป็นแบบข้ามแพลตฟอร์ม
  • GUI ไม่ยึดติดกับความข้ามแพลตฟอร์ม แต่เลือกแนวทางเนทีฟตามแต่ละแพลตฟอร์ม
• เขามองว่าโปรเจ็กต์โอเพนซอร์สและอินเทอร์เน็ตควรเป็นการรวมตัวของ เผ่าต่าง ๆ ที่แตกต่างกัน
• เขาไม่ชอบให้ภาษาโปรแกรมกลายเป็นตัวหารร่วมน้อยสุดที่มีทุกฟีเจอร์ที่ทุกคนต้องการ และบอกว่าข้อจำกัดต่างหากที่สร้างความคิดสร้างสรรค์และวัฒนธรรม
• เขาบอกว่าชอบทั้งตัวภาษาและปรัชญาของ Rust แต่ไม่ชอบวัฒนธรรม Rust พร้อมแยกให้ชัดว่านั่นไม่ได้หมายความว่าคนในชุมชน Rust เป็นคนไม่ดี
• Zig มีจุดยืนที่เด่นชัดและแบ่งขั้วทั้งในด้านเทคโนโลยี การจัดการชุมชน การระดมทุน PR บล็อกโพสต์ และวิธีการสื่อสาร และ Hashimoto ก็บอกว่าเขาเคารพความประหลาดนั้น พร้อมสนับสนุนทางการเงินและใช้งานมันต่อไป
• หากจะปล่อยของได้เร็วแต่ยังมีคุณภาพ จำเป็นต้องเข้าใจไม่ใช่แค่ปัญหาเฉพาะหน้าของลูกค้า แต่รวมถึงบริบทที่ทำให้ผู้ใช้ไปเจอปัญหานั้น และปัญหาต้นน้ำที่อยู่ก่อนหน้า
• เขาบอกว่าไม่รู้จะแก้เรื่องนี้อย่างไรในระดับองค์กรใหญ่ แต่สำหรับตัวเอง เขาตัดสินใจโดยยืนอยู่ในฐานะผู้ใช้รายใหญ่ของซอฟต์แวร์ที่ตัวเองสร้าง
• AI ใช้แบบคร่าว ๆ เพื่อทำเดโมหรือเช็กทิศทางได้ แต่โค้ดที่จะปล่อยจริงต้องอ่าน ทำความเข้าใจ และส่งมอบอย่างมีคุณภาพ
• ในการเรียนรู้ C สิ่งสำคัญกว่าตัวภาษา คือความเข้าใจว่าคอมพิวเตอร์ทำงานอย่างไร
  • ต้องเข้าใจการจัดตาราง CPU, หน่วยความจำ, ลำดับชั้นของแคช, ระบบไฟล์, ดิสก์ และการเข้าถึงไฟล์
  • การทำงานใกล้ชั้น syscall ด้วยภาษาอย่าง C, Zig และ Rust ทำให้เข้าใจได้ง่ายขึ้นว่าเกิดอะไรขึ้น
  • API สำหรับเปิดไฟล์ใน Python, JavaScript และ Ruby ซ่อนรายละเอียดไว้มาก
  • เขาแนะนำว่าอย่ามองฟังก์ชันใน standard library เป็นของที่ต้องเชื่อโดยอัตโนมัติ เพราะมันก็เป็นโค้ดที่ใครบางคนเขียนไว้ และควรอ่านกับขุดลึกเพื่อเข้าใจการทำงานของมัน

[unsure4000]

โพสต์ขึ้นมาไล่ ๆ กัน แต่บรรยากาศต่างกันมากจนตลกดี 555555
ความเห็นของผมเกี่ยวกับการเขียน Bun ใหม่ด้วย Rust

[sea715]

• ข้อถกเถียงส่วนใหญ่ไม่ได้เกี่ยวกับไอเดีย แต่เกี่ยวกับอัตตา
  555...

[ffdd270]

55555555555555555555555555555555555

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• เป็นบทสัมภาษณ์ที่ยอดเยี่ยม และประโยคที่ชอบที่สุดคือ “แม้จะไม่ได้เห็นด้วยทั้งหมด แต่ฉันเคารพ ความแปลกแบบมั่นใจ มากจริงๆ”
  อยากให้มีท่าทีแบบนี้มากขึ้น

• ถ้าจะพูดถึง กรณีนำร่อง และวิวัฒนาการของเทอร์มินัล ก็น่าจะต้องพูดถึง Arcan กับ cat9 อย่างน้อยบ้าง
  https://arcan-fe.com/2022/04/…

• ตรงที่บอกว่า “PowerShell จัดการกับ ข้อมูลแบบมีโครงสร้าง ได้ดี” ทำให้นึกถึงคำตอบนี้ของ Jörg W Mittag
  ถ้าใช้อาร์กิวเมนต์แบบมีชนิด การพาร์สทั้งหมดจะเป็นหน้าที่ของ PowerShell
  แค่จินตนาการว่าแท็บ Neovim เปิดพร้อมกันเป็นแท็บหน้าต่างเนทีฟก็น่าตื่นเต้นมากแล้ว
  การทำงานอยู่เหนือชั้น system call โดยตรงแบบ C, Zig, Rust ช่วยให้เข้าใจได้มากว่าเกิดอะไรขึ้น
  กระบวนการลอกชั้นนามธรรมระหว่างเครื่องกับโปรแกรมเมอร์ออกเพื่อให้แตะถึงชั้นฐานนั้นทั้งสนุกและทำให้เข้าใกล้แก่นของปัญหามากขึ้น
  โดยปกติ standard library มักตั้งเป้าที่ความพกพาได้ จึงบรรจุเพียงตัวหารร่วมต่ำสุดของความสามารถระบบปฏิบัติการ แต่เมื่อใช้ศักยภาพของแพลตฟอร์มได้เต็มที่ การเขียนโปรแกรมจะสนุกขึ้นมาก
  ท่าทีที่บอกว่าแม้แต่ฟังก์ชันใน standard library ก็เป็นโค้ดที่มีคนเขียนขึ้นมา จึงไม่ควรถือเป็นเรื่องธรรมดาแต่ควรเปิดอ่านดูด้วย เป็นสิ่งที่น่าเคารพมาก
  ฉันก็อยากรู้เรื่องโปรแกรมผู้สนับสนุนของ Ghostty ให้มากกว่านี้ด้วย ดูเหมือนจะจัดตั้งเป็นนิติบุคคลไม่แสวงกำไร เลยสงสัยว่ามันประสบความสำเร็จและพึ่งพาตัวเองได้มากแค่ไหน

• PowerShell บน Windows มีข้อดีตรงที่ตามคำนิยามนี้มันเป็นแบบ internal อย่างสมบูรณ์ แต่เพราะสร้างอยู่บน .NET framework และเข้าถึงพร้อมทำงานร่วมกับ Windows API ได้แทบทั้งหมด ในทางปฏิบัติจึงไม่ได้ถูกจำกัดมากนัก
  UNIX นั้นเป็นแบบ external ตามการออกแบบ และคำตอบเชิงโครงสร้างของ Nushell เท่าที่เข้าใจคือเป็น internal อย่างเคร่งครัด จึงขยายต่อได้ยากกว่า
  Oils เดิมพันกับ json หรือส่วนขยายของตัวเองอย่าง json8 เพื่อการทำงานร่วมกันแบบมีโครงสร้างภายนอก แต่ทั้งคู่ก็ยังให้ความรู้สึกว่าจำกัดอยู่มากเมื่อเทียบกับ PowerShell
  บางทีก็คิดว่าถ้าทุกคนตกลงกันว่าจะส่งเพียง msgpack ออกทาง stdout และเปลี่ยนทุกเทอร์มินัลให้เป็นตัวดู msgpack จะเป็นอย่างไร ถึงขั้นน่าจะต้องยื่นคำร้องให้ใส่การ serialize/deserialize ผ่าน pipe ลงใน libc
  ไม่ใช่แค่องค์กรมาตรฐานเทอร์มินัลที่หายไป แต่โลกของเชลล์เองก็แทบไม่มีนวัตกรรมในระดับ production เลย
  Bash ยังเพิ่มฟีเจอร์ที่มีอยู่แล้วใน Kornshell อยู่จนทุกวันนี้ ใน Unix shell ก็ยังมีหลุมพรางมากเกินไปที่ไม่มีใครรู้จะเลิกมันอย่างไร และ POSIX ก็แทบไม่ขยับ
  ฉันยังยึดฝันว่า Oils หรือ Nushell จะถูกนำไปใช้ในดิสโทรหลักๆ จนผู้คนตระหนักได้ว่านวัตกรรมในพื้นที่นี้เป็นเรื่องดี
  อย่างน้อย kitty ก็ได้เปิดทางในโลกเทอร์มินัลอย่างชัดเจน และแม้จะยังขาดการประสานกัน ก็ดูเหมือนจะมาถึงขั้นที่นวัตกรรมเริ่มเกิดขึ้นแล้ว

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

• เห็นด้วยกับแนวคิดที่ว่าควรมี ฟอร์กส่วนตัวเพื่อการดูแลรักษา มากกว่านี้ แต่ก็ไม่แน่ใจว่าจะส่งเสริมอย่างไรดี
  สำหรับคนที่อยู่ปลายล่างของสเปกตรัมความรู้สึกมีสิทธิ์ อาจไม่ได้สนใจองค์ประกอบฝั่งองค์กรอย่างสัญญาซัพพอร์ตแบบจ่ายเงิน แต่อยากได้แค่ความสะดวกในการติดตั้งตรงจาก package manager ที่ตัวเองชอบ
  ต้องหาทางลดแรงเสียดทานช่วงแรกในการก้าวจาก brew install หรือ apt install ไปสู่ขั้นที่ต้องจัดการกับ repository ที่โคลนมาและเครื่องมือ build
  คอมไพเลอร์ที่เร็วขึ้นอาจช่วยได้
  แต่สำหรับซอฟต์แวร์ที่อ่อนไหวด้านความปลอดภัย การที่ผู้ใช้ไม่แก้ไขอะไรไปมากอาจเป็นผลดีกว่า ดังนั้นแรงเสียดทานนั้นเองบางครั้งก็เป็นฟีเจอร์

• เห็นด้วยอย่างมากว่าระหว่าง n-screen กับสเปกของปุ่มต่างๆ ควรมีบางอย่างขั้นกลางสำหรับ UI สมัยใหม่
  บางทีแค่เรียกมันว่า ชั้นความหมาย ก็น่าจะพอ
  ถ้ามีชั้นนี้ ก็จะทำให้เครื่องมือแบบ agentic เครื่องมือหน้าจอหลัก accessibility รวมถึง widget และ control ที่ประกอบร่วมกันได้เป็นไปได้
  ท้ายที่สุดแล้ว n-screen กับปุ่มต่างๆ ก็ดูเหมือนเป็นขอบเขตซ้ายขวาของคำถามว่าจะสื่อเนื้อหาได้มากแค่ไหน
  ในอุดมคติ ชั้นความหมายนี้ควรนำสิ่งอย่างหลายเคอร์เซอร์ การตัดบรรทัดตามคำแทนการตัดตามตัวอักษร และ overlay (เช่น z-index, cell blending เป็นต้น) มาด้วย