โปรแกรม Build It Yourself ที่ลงมือสร้างเองโดยตรง

 (lucumr.pocoo.org)
2 คะแนน โดย GN⁺ 2025-01-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • มุมมองอีกแบบต่อการพึ่งพาไลบรารี

    • เสนอมุมมองใหม่ต่อการพึ่งพาไลบรารี โดยควรลดการใช้งานที่มากเกินไปและหันมาเขียนโค้ดด้วยตนเองมากขึ้น

  • ปัญหาของการพึ่งพาไลบรารี

    • "การสิ้นเปลืองจากการพึ่งพาไลบรารี" คือวงจรไม่รู้จบของการอัปเดต แพตช์ การตรวจสอบ และการพึ่งพาแบบส่งต่อที่นักพัฒนาติดตั้งเพื่อเพิ่มผลิตภาพ
    • JavaScript และ Rust เปราะบางต่อปัญหาการพึ่งพาไลบรารีเป็นพิเศษ ตัวอย่างเช่น โปรเจ็กต์ Tokio ใหม่มี 28 crate และโปรเจ็กต์ Rocket เพิ่มขึ้นเป็น 172 crate

  • ปัญหาขนาดเทอร์มินัล

    • crate terminal_size ให้ฟังก์ชันง่าย ๆ สำหรับวัดขนาดเทอร์มินัล แต่ต้องใช้ crate เพิ่มเติมอีกหลายตัว
    • ส่งผลให้เกิดสถานการณ์ที่ต้องคอมไพล์ฟังก์ชันอื่น ๆ อีกหลายพันรายการ

  • ความจำเป็นของการพึ่งพาไลบรารี

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

  • เป้าหมายของโค้ด

    • โค้ดควรถูกเขียนในแบบที่ไม่จำเป็นต้องอัปเดต ใน ecosystem ของ Rust โค้ดที่มีความเสถียรกลับมักเสียเปรียบ

  • ข้อดีของการเขียนโค้ดเองโดยตรง

    • เมื่อเขียนโค้ดเอง จะไม่ต้องใช้ crate ใหม่ และลดความจำเป็นในการบำรุงรักษา
    • สามารถใช้เครื่องมืออย่าง ChatGPT เพื่อเขียน implementation ที่ไม่มี dependency ได้อย่างรวดเร็ว

  • โอเพนซอร์สและวัฒนธรรมองค์กร

    • วัฒนธรรมการรีวิวโค้ดขององค์กรส่งอิทธิพลต่อซอฟต์แวร์โอเพนซอร์ส
    • การใช้ไลบรารีใหม่มักถูกมองในแง่บวก

  • ความจำเป็นของมุมมองใหม่

    • ควรชื่นชมวิศวกรที่ลงมือเขียนฟังก์ชันเล็ก ๆ เอง
    • ควรมองกราฟ crate ขนาดใหญ่ด้วยความสงสัย

  • ไลบรารีสำคัญ

    • ยังมีไลบรารีสำคัญที่ช่วยแก้ปัญหาซับซ้อนอยู่ เช่น ไลบรารีกราฟิกหรือการทำ implementation ของโปรโตคอล

  • ความสำคัญของการสร้างเอง

    • ควรยกย่องการสร้างเองเมื่อเหมาะสม
    • ควรให้เครดิตแก่ผู้เขียนไลบรารีที่สร้างไลบรารีโอเพนซอร์สที่มี dependency น้อยหรือไม่มีเลย

  • บทสรุป

    • ควรเปลี่ยนทิศทางไปสู่การลด dependency และเขียนโค้ดด้วยตนเองมากขึ้น
    • minijinja เป็นตัวอย่างของการลด dependency ให้เหลือน้อยที่สุด โดยพึ่งพาเพียง serde ตัวเดียว

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

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

 
GN⁺ 2025-01-26
ความคิดเห็นจาก Hacker News

  • ชอบภาษา Rust แต่ไม่ชอบปัญหาเรื่อง dependency ของ Rust การจัดการ dependency ของ C++ ดีกว่า ใน C++ สามารถควบคุม dependency ได้ด้วยตัวเอง แต่ใน Rust มักเกิด dependency จำนวนมากจนทำให้เลิกใช้ไป ในแง่ความปลอดภัยก็ไม่รู้ว่าตัวเองกำลังแจกจ่ายอะไรอยู่ Rust ไม่มี ABI compatibility และวัฒนธรรม shared library ก็ยังไม่แข็งแรง สิ่งนี้ทำลายโมเดลการแจกจ่ายแพ็กเกจของ OS

  • API ของเทอร์มินัลยังไม่เสถียร TIOCGWINSZ ioctl ไม่ได้ถูกทำให้เป็นมาตรฐาน และการเพิ่มฟังก์ชัน tcgetwinsize() เข้าไปใน POSIX เพิ่งเกิดขึ้นในปี 2024 ฝั่ง Windows ซับซ้อนยิ่งกว่า

  • นำเว็บแอปที่สร้างไว้ในปี 2006 กลับมาชุบชีวิต ออกแบบกระบวนการ deploy ของแอปอย่างเกินความจำเป็นเพื่อเรียนรู้เทคโนโลยี CI/CD ใหม่ ๆ ใช้ PHP และ MySQL และเขียนโค้ดเองเกือบทั้งหมด ใช้เวลาแค่หนึ่งชั่วโมงในการปลุกแอปอายุ 19 ปีให้กลับมาใช้งานได้ ในทางกลับกัน แอป Spring Boot ที่ใช้อยู่ในงานปัจจุบันกลับอัปเดตได้ยากเพราะปัญหา dependency

  • NodeJS ส่งผลอย่างมากต่อเส้นทางอาชีพ แต่ NPM ก่อปัญหาไว้มากมาย พอจะเพิ่ม dependency ใหม่ก็มักไปชนกับ dependency อื่น ในกรณีของ Expo มีปัญหาที่โปรเจกต์ React Native พื้นฐาน build บน Android ไม่ได้ เรื่องนี้ทำให้รู้สึกมั่นใจขึ้นว่าแม้แต่โปรเจกต์ขนาดใหญ่ก็ยังปล่อยเทมเพลตที่ใช้งานไม่ได้ออกมาได้

  • ecosystem ของ Rust มี dependency มากเมื่อเทียบกับ Go ใน Go นั้น interface ถูกทำให้สอดคล้องกันโดยปริยาย จึงไม่จำเป็นต้องมี dependency เพิ่มเติม

  • abstraction ของไลบรารีมีต้นทุนแฝงอยู่ เมื่อแพ็กเกจเปลี่ยนดีไซน์ก็ทำให้เกิดความไม่เสถียร สิ่งที่เรียบง่ายมักอยู่รอดได้นานที่สุด เห็นปัญหาคล้ายกันนี้ไม่ใช่แค่ใน Rust แต่ในภาษาอื่นด้วย

  • ให้ ChatGPT หรือ Cursor สร้าง implementation ที่ไม่มี dependency ให้แบบรวดเร็วกลับจะเร็วกว่า dependency ของบริการ SaaS/3rd party หลายอย่างเป็นปัญหาที่ถูกแก้ไปแล้ว

  • Flask และ Bottle มีความสามารถคล้ายกัน แต่ Flask ได้รับความนิยมมากกว่า Bottle เป็นไฟล์เดียวและไม่มี dependency จึงคัดลอกเข้าโปรเจกต์ได้ง่าย อย่างไรก็ตาม มันไม่ได้ตามแนวปฏิบัติ Python สมัยใหม่ จึงให้ความรู้สึกล้าสมัย

  • ต้องการวิศวกรที่มีความสามารถและสามารถพัฒนาโซลูชันได้ด้วยตัวเอง ซึ่งมักสร้างโซลูชันที่ดีกว่าไลบรารีเดิมได้ไม่ยาก ในโปรเจกต์หนึ่งเคยเขียน parser สำหรับ markdown แบบดัดแปลงเอง แต่เพื่อนร่วมทีมไม่ยอมใช้เพราะกังวลเรื่องการบำรุงรักษา

  • การคอมไพล์ฟังก์ชันนับร้อยเพียงเพื่อใช้งานแค่ฟังก์ชันเดียวเป็นปัญหา ในโปรเจกต์ที่อัปเดต dependency ของ 3rd party นั้น มีการใช้เพียงเมธอดเดียวจากไลบรารีคณิตศาสตร์ จึงแนะนำให้วิศวกรไปดูหน้า Wikipedia แล้วเขียนเมธอดนั้นขึ้นมาเอง ปัญหาไม่ใช่การใช้ dependency ของ 3rd party แต่คือเราต้องการแนวคิดในการดึงมาใช้แค่ส่วนเล็ก ๆ ของไลบรารี บางที "microframework" อาจเป็นคำตอบได้