เครื่องมือแสดงโครงสร้างไดเรกทอรีที่พัฒนาด้วย Rust ชื่อ Istr ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนา ไม่เพียงแต่เพราะฟีเจอร์ที่น่าประทับใจ แต่ยังเป็นเพราะปัญหาที่คุ้นเคยซึ่งรบกวนแอปพลิเคชัน Rust สมัยใหม่หลายตัว นั่นคือปัญหาขนาดไฟล์ binary ที่บวมโต
Istr วางตำแหน่งตัวเองเป็นทางเลือกที่เร็วแรงเหมือนสายฟ้าแลบสำหรับคำสั่ง tree แบบดั้งเดิมของ Unix โดยเสนอทั้งการแสดงผลแบบ command-line แบบดั้งเดิมและส่วนติดต่อผู้ใช้แบบโต้ตอบในเทอร์มินัล เครื่องมือนี้ใช้ประโยชน์จากการสแกนไดเรกทอรีแบบขนานและรวมฟีเจอร์สมัยใหม่ เช่น การรวมเข้ากับ Git ไอคอนไฟล์ และความสามารถในการค้นหาแบบ fuzzy อย่างไรก็ตาม ความสนใจของชุมชนได้เปลี่ยนจากการชื่นชมฟังก์ชันการทำงานไปสู่การตั้งคำถามเกี่ยวกับการใช้ทรัพยากร
คุณสมบัติหลักของ Istr
- การสแกนไดเรกทอรีแบบขนานโดยใช้ thread pool ของ Rayon
- โหมด TUI แบบโต้ตอบพร้อมการนำทางด้วยคีย์บอร์ด
- การรวมสถานะ Git (แฟล็ก -G)
- รองรับไอคอนไฟล์ (ต้องใช้ Nerd Font)
- การเคารพไฟล์ Gitignore (แฟล็ก -g)
- ตัวเลือกการแสดงสิทธิ์และขนาดไฟล์
- การรวม fuzzy search กับ fzf
ขนาด Binary กลายเป็นประเด็นหลัก
ประเด็นที่ถกเถียงกันมากที่สุดเกิดขึ้นเมื่อผู้ใช้ค้นพบว่าไฟล์ binary ที่คอมไพล์แล้วของ Istr มีน้ำหนักถึง 4.3MB ในโหมด release เมื่อเทียบกับคำสั่ง tree แบบดั้งเดิมที่มีขนาดเพียง 80KB ซึ่งแสดงให้เห็นความแตกต่างประมาณ 50 เท่าสำหรับสิ่งที่หลายคนถือว่าเป็นฟังก์ชันหลักที่คล้ายคลึงกัน ความแตกต่างนี้ยิ่งชัดเจนมากขึ้นเมื่อเปรียบเทียบกับโปรแกรม shell ทั้งหมด เช่น dash (144KB) หรือ mksh (292KB)
สมาชิกในชุมชนไม่ได้เก็บการวิจารณ์ไว้ นักพัฒนาคนหนึ่งกล่าวอย่างตรงไปตรงมาว่า 4.3MB นั้นใหญ่มากสำหรับสิ่งที่มันทำ และตั้งคำถามว่าความบวมโตทั้งหมดนี้มาจากไหน ความกังวลเรื่องขนาดนี้สะท้อนถึงความหงุดหงิดในวงกว้างเกี่ยวกับซอฟต์แวร์สมัยใหม่ที่กินทรัพยากรมากขึ้นเรื่อยๆ โดยมีผู้ใช้บางคนรายงานว่าการบวมโตของแอปกำลังบังคับให้พวกเขาต้องอัปเกรดพื้นที่จัดเก็บข้อมูลในอุปกรณ์บ่อยขึ้น
การเปรียบเทียบขนาดไฟล์ Binary
- Istr (debug build): 53MB
- Istr (release build): 4.3MB
- Istr (optimized): 2.2MB
- คำสั่ง tree แบบดั้งเดิม: 80KB
- อัตราส่วนขนาด: ใหญ่กว่า tree ประมาณ 50 เท่า (โหมด release)
ความพยายามในการปรับปรุงแสดงให้เห็นความหวัง
แม้จะมีการวิจารณ์ แต่การถกเถียงได้เผยให้เห็นว่าสามารถลดขนาดได้อย่างมีนัยสำคัญผ่านการปรับปรุงการคอมไพล์ต่างๆ นักพัฒนา Rust ที่มีประสบการณ์ได้แสดงให้เห็นว่าไฟล์ binary สามารถบีบอัดให้เหลือประมาณ 2.2MB ได้โดยใช้การตั้งค่าคอมไพเลอร์แบบเข้มงวด รวมถึง link-time optimization การตัด symbol และ compilation flags ที่เน้นขนาด
การถกเถียงนี้เน้นให้เห็นถึงการแลกเปลี่ยนที่น่าสนใจในการพัฒนาซอฟต์แวร์สมัยใหม่ ในขณะที่ขนาดที่ใหญ่ขึ้นของ Istr เกิดจากชุดฟีเจอร์ที่หลากหลาย รวมถึงการประมวลผลแบบขนานด้วย thread ส่วนประกอบ GUI แบบโต้ตอบ และการรวมเข้ากับ Git repository แต่นักวิจารณ์โต้แย้งว่าการเพิ่มเติมเหล่านี้ไม่สามารถอธิบายการเพิ่มขนาดอย่างมากเมื่อเทียบกับทางเลือกแบบดั้งเดิมได้
การตั้งค่าการเพิ่มประสิทธิภาพการคอมไพล์ Rust
[profile.release]
codegen-units = 1
opt-level = "s"
lto = true
panic = "abort"
strip = "symbols"
การตั้งค่าเหล่านี้สามารถลดขนาดไฟล์ไบนารีจาก 4.3MB ลงมาเหลือประมาณ 2.3MB
คุณค่าทางเทคนิคเทียบกับประสิทธิภาพการใช้ทรัพยากร
นอกเหนือจากการถกเถียงเรื่องขนาดแล้ว ผู้ใช้ยังยอมรับความสำเร็จทางเทคนิคของ Istr เครื่องมือนี้มีความสามารถในการเดินผ่านไดเรกทอรีแบบขนานและส่วนติดต่อแบบโต้ตอบที่ขัดเกลาแล้ว ซึ่งได้รับคำชื่นชมจากนักพัฒนาที่ชื่นชอบแนวทางสมัยใหม่ในการนำทางระบบไฟล์ การรวมเข้ากับ fuzzy finder เช่น fzf และความสามารถในการใช้เป็นตัวเปลี่ยนไดเรกทอรีแบบภาพได้สร้างความประทับใจให้กับ power user โดยเฉพาะ
Binary นี้มีขนาด 53M เช่นกัน ในขณะที่ /usr/sbin/tree มีขนาด 80K ในเครื่องของฉัน -- ไม่ใช่ปัญหาจริงๆ สำหรับพื้นที่จัดเก็บในปัจจุบัน แต่ความแตกต่างประมาณ 500-1000 เท่านั้นไม่ใช่เรื่องเล็กน้อย
ผู้เขียนซึ่งกำลังทำงานกับแพ็กเกจ Rust แรกของตน แสดงความขอบคุณสำหรับคำติชมจากชุมชนและยอมรับความกังวลเรื่องขนาด binary การตอบสนองนี้สะท้อนถึงเส้นโค้งการเรียนรู้ทั่วไปสำหรับนักพัฒนาที่เปลี่ยนมาใช้ Rust ซึ่ง dependency ที่หลากหลายและ static linking ของระบบนิเวศสามารถนำไปสู่ไฟล์ binary ที่ใหญ่เกินคาดหากไม่มีการปรับปรุงอย่างระมัดระวัง
ขนาดไฟล์ไบนารีของ Shell สำหรับอ้างอิง
- bash: 1,236KB
- dash: 144KB
- mksh: 292KB
- zsh: 848KB
- busybox-static: 1,936KB (รวมเครื่องมือหลายตัว)
บทสรุป
ความขัดแย้งเรื่อง Istr สรุปความตึงเครียดในวงกว้างในการพัฒนาซอฟต์แวร์สมัยใหม่ระหว่างความหลากหลายของฟีเจอร์และประสิทธิภาพการใช้ทรัพยากร ในขณะที่เครื่องมือนี้แสดงให้เห็นความสามารถทางเทคนิคที่น่าประทับใจและเป็นตัวแทนของงานวิศวกรรมที่มั่นคง แต่การที่ชุมชนมุ่งเน้นไปที่ขนาด binary สะท้อนถึงความกังวลที่เพิ่มขึ้นเกี่ยวกับการบวมโตของซอฟต์แวร์ในยุคที่ฮาร์ดแวร์มีพลังมากขึ้นเรื่อยๆ การถกเถียงนี้เป็นเครื่องเตือนใจที่มีค่าว่าแม้ในปี 2025 นักพัฒนาต้องสร้างสมดุลระหว่างฟังก์ชันการทำงานกับการใส่ใจทรัพยากร โดยเฉพาะเมื่อสร้างทางเลือกสำหรับเครื่องมือที่มีชื่อเสียงและมีน้ำหนักเบา
อ้างอิง: Istr