อัตลักษณ์ที่ถูกพันธนาการ: เมื่อ Rust Closures สะท้อนตรรกะแห่งการครอบครอง

Share
อัตลักษณ์ที่ถูกพันธนาการ: เมื่อ Rust Closures สะท้อนตรรกะแห่งการครอบครอง
Photo by Markus Spiske on Unsplash

ในโลกของ Rust “ความอิสระ” เป็นเพียงภาพลวงตา เพราะทุกการขยับเขยื้อนของข้อมูลล้วนมีพันธนาการที่เรียกว่า Ownership กำกับอยู่เสมอ


หากเราเปรียบฟังก์ชันทั่วไปเป็นเหมือนคนแปลกหน้าที่เดินผ่านมาแล้วจากไป Closures ก็คงเป็นเหมือน “เงา” ที่ไม่ได้อยู่โดดเดี่ยว แต่มันพร้อมจะฉุดกระชากเอาสิ่งแวดล้อมรอบตัว (Environment) เข้ามาเป็นส่วนหนึ่งของตัวมันเอง กลไกที่ดูเหมือนเรียบง่ายนี้กลับซ่อนนัยทางปรัชญาที่น่าสนใจเกี่ยวกับการมีอยู่และการครอบครอง

1. การเฝ้ามอง (Immutable Borrowing)

เมื่อ Closure เลือกที่จะ Capture ข้อมูลแบบ Immutable Borrow (&T) มันทำตัวเป็นเพียง "ผู้สังเกตการณ์" มันจดจำค่าไว้เพียงเพื่อนำไปใช้งาน แต่ไม่อาจเข้าไปเปลี่ยนแปลงสิ่งที่มันเฝ้ามอง

ในทางปรัชญา นี่คือสภาวะของ Stoicism (สโตอิก) ที่สมบูรณ์แบบ มาร์กุส ออเรลิอุส เคยกล่าวถึงการมองโลกตามความเป็นจริงโดยไม่เอาตัณหาเข้าไปเจือปน ใน Rust นี่ก็คือ Trait Fn — การมีอยู่ของเรา (Closure) ไม่ได้ทำให้โลกภายนอก (Data) ปั่นป่วน

ความสงบที่แท้จริงไม่ใช่การไร้ซึ่งข้อมูล แต่คือการถือครองความจริงไว้ในมือ… โดยไม่ยอมให้มันกลายเป็นเจ้าของหัวใจเรา

2. การเป็นผู้กระทำและภาระแห่งความเปลี่ยนแปลง (Mutating)

นาทีที่คุณต้องการ “แก้ไข” สิ่งที่ถูก Capture มาในภาษา Rust นั้น Closure จะยกระดับ Trait เป็น FnMut ทันที มันคือการถือครอง Mutable Reference (&mut T)

นี่คือจุดเปลี่ยนจากผู้สังเกตไปเป็น “ผู้กระทำ” ตามแนวคิดของ Existentialism (อัตถิภาวนิยม) ที่ว่าตัวตนของเราถูกสร้างผ่านการกระทำ แต่การเป็นผู้กระทำใน Rust นั้นมีราคาแพง คุณต้องได้รับสิทธิ์ขาด (Exclusive Access) เพียงผู้เดียวในเวลานั้น

หากคุณพยายามแก้ไขโลก (State) ในขณะที่คนอื่นก็กำลังเฝ้ามองมันอยู่ ระบบจะสั่ง “Panic” หรือคอมไพล์ไม่ผ่าน นี่คือสัจธรรมที่ว่า ความเปลี่ยนแปลงที่ไร้ระเบียบนำมาซึ่งความพินาศเสมอ

3. การครอบครองจนดับสูญ (Moving & Consuming)

สภาวะสุดท้ายคือความดิบเถื่อนที่สุด เมื่อ Closure ใช้คีย์เวิร์ด move เพื่อยึดกรรมสิทธิ์โดยสมบูรณ์ และเมื่อมันใช้งานข้อมูลนั้นจนเสร็จสิ้น ข้อมูลนั้นจะมอดไหม้ไปพร้อมกับตัวมันเอง (Trait FnOnce)

Michel Foucault เคยวิเคราะห์เรื่อง “อำนาจ” (Power) ว่าอำนาจที่เบ็ดเสร็จที่สุดคือการกลืนกินตัวตนนั้น ๆ เข้ามาเป็นส่วนหนึ่งของระบบ เมื่อคุณครอบครองบางอย่างอย่างสมบูรณ์ สิ่งนั้นจะสูญเสียอัตลักษณ์เดิมและสลายไปภายใต้เจตจำนงของผู้ถือครอง

บทสรุป

บทเรียนจาก Comprehensive Rust ไม่ได้เป็นเพียงคู่มือวิศวกรรม แต่มันคือ คัมภีร์การจัดการความสัมพันธ์

ในชีวิตจริง เรามักจะ “Capture” สิ่งต่าง ๆ เข้ามาในใจตลอดเวลา ทั้งความทรงจำ ความแค้น หรือความคาดหวัง บ่อยครั้งที่เราไม่รู้ตัวว่าเรากำลังถือครองมันแบบไหน:

  • เราแค่เฝ้ามองมันเพื่อเรียนรู้? (Fn)
  • เราพยายามจะบงการมันตามใจชอบ? (FnMut)
  • หรือเรายึดติดกับมันจนยอมให้มันทำลายเราไปพร้อมกัน? (FnOnce)

Rust สอนให้เราคิดก่อนจะ Capture เพราะการจัดการหน่วยความจำที่ผิดพลาดนำไปสู่ Memory Leak แต่การจัดการ “ความยึดติด” ที่ผิดพลาด… นำไปสู่ความทุกข์ที่ไม่มีวันสิ้นสุด

เพราะสุดท้ายแล้ว บรรทัดคำสั่งที่ปลอดภัยที่สุด คือบรรทัดที่เราเข้าใจว่าเรากำลัง “แบก” อะไรไว้บ้าง

เกี่ยวกับผู้เขียน: Uncle Quin — Software Engineer ผู้หลงใหลในการเชื่อมโยงวิศวกรรมซอฟต์แวร์เข้ากับปรัชญา

หากบทความนี้มีประโยชน์

คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง

ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer

แบบไม่ต้องใส่สูท

แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ

Read more

Accepted Responsibility

Accepted Responsibility

ช่วงนี้ผมกำลังอ่านหนังสือ Extreme Programming Explained ของ Kent Beck แล้วก็ได้เจอหัวข้อหนึ่งที่กระทบใจ คือ principle ที่เรียกว่า Accepted Responsibility Principle คืออะไร? ในหนังสืออธิบายว่า Principle คือหลักการที่ทำให้ Values ของ XP กลายเป็น Practices ได้

By Chokchai Phatharamalai
The Five Ideals

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

By Chokchai Phatharamalai
Communication, Reliability and Modern concepts - System Design, Simply Explained

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API

By Boonsong Srithong
Race condition

Race condition

ผมกำลังอ่านหนังสือ The Unicorn Project ซึ่งเป็นนิยายเกี่ยวกับ developer สาวคนหนึ่งที่ใช้ชีวิตในองค์กรท่ามกลางกระแส digital disruption อ่านแล้วสนุกมาก เป็นเรื่องที่ตื่นเต้น และหลาย ๆ dynamic ที่เกิดขึ้นก็คล้ายกับที่ผมพบเจอในบริษัทซอฟต์แวร์ เลยทำให้

By Chokchai Phatharamalai