ภูมิหลัง
- Erlang เป็นภาษาที่พัฒนาขึ้นเพื่อสร้างระบบกระจายที่เชื่อถือได้ โดยเริ่มต้นจากไลบรารีของ Prolog ก่อนจะพัฒนามาเป็นภาษาอิสระ
- ถูกใช้ที่ Ericsson เพื่อเขียนโปรแกรมสวิตช์โทรศัพท์ และในปี 1998 ได้เปลี่ยนเป็นโอเพนซอร์ส
- Joe Armstrong เป็นหนึ่งในผู้ออกแบบหลักของ Erlang และวิทยานิพนธ์ปริญญาเอกของเขาว่าด้วยวิธีสร้างระบบกระจายที่เชื่อถือได้แม้ซอฟต์แวร์จะมีข้อผิดพลาด
พฤติกรรม (Behaviours)
- พฤติกรรมของ Erlang คล้ายกับ interface ใน Java หรือ Go โดยเป็นชุดของลายเซ็นชนิดข้อมูลที่สามารถมีการนำไปใช้ได้หลายแบบ
- พฤติกรรมทำให้ผู้พัฒนาต้องเขียนเพียงโค้ดที่กำหนดตรรกะทางธุรกิจของโปรแกรม ส่วนโค้ดโครงสร้างพื้นฐานจะถูกจัดเตรียมให้อัตโนมัติ
- พฤติกรรมถูกเขียนโดยผู้เชี่ยวชาญและอิงตามแนวปฏิบัติที่ดีที่สุด
พฤติกรรมเซิร์ฟเวอร์ทั่วไป
gen_server ถูกอธิบายผ่านตัวอย่างการทำ key-value store
handle_call ทำหน้าที่อัปเดตสถานะหรือค้นหาคีย์ โดยความพร้อมกันทั้งหมดถูกซ่อนไว้ในคอมโพเนนต์ gen_server
พฤติกรรมตัวจัดการอีเวนต์
gen_event เป็นตัวจัดการอีเวนต์ ใช้ลงทะเบียนตัวจัดการอีเวนต์และเรียกใช้งานเมื่อมีข้อความเข้ามา
- มีประโยชน์สำหรับการบันทึกข้อผิดพลาด และมีตัวอย่าง logger แบบง่ายให้ดู
พฤติกรรมเครื่องสถานะ
gen_fsm ถูกเปลี่ยนชื่อเป็น gen_statem และเหมาะสำหรับการนำโปรโตคอลไปใช้งานจริง
พฤติกรรมซูเปอร์ไวเซอร์
- ซูเปอร์ไวเซอร์ทำหน้าที่ตรวจสอบว่าโปรเซสอื่น ๆ ทำงานได้ตามปกติ และจะรีสตาร์ตตามกลยุทธ์ที่กำหนดไว้ล่วงหน้าเมื่อเกิดความล้มเหลว
- กลยุทธ์
one_for_one จะรีสตาร์ตเฉพาะโปรเซสที่ล้มเหลว ส่วนกลยุทธ์ one_for_all จะรีสตาร์ตลูกทั้งหมดเมื่อมีโปรเซสหนึ่งตัวล้มเหลว
พฤติกรรมแอปพลิเคชันและรีลีส
- แอปพลิเคชันประกอบด้วยต้นไม้ซูเปอร์ไวเซอร์และทุกสิ่งที่จำเป็น ส่วนรีลีสคือการแพ็กเกจแอปพลิเคชันหนึ่งตัวหรือมากกว่านั้น
- ต้องสามารถย้อนกลับได้เมื่อการอัปเกรดล้มเหลว
การนำพฤติกรรมไปใช้
- มากกว่าที่จะเป็นโปรเซสแบบเบาของ Erlang และการส่งข้อความ โครงสร้างของพฤติกรรมต่างหากที่นำไปสู่ซอฟต์แวร์ที่เชื่อถือได้
- หากต้องการนำพฤติกรรมไปใช้ในภาษาอื่น สามารถเริ่มจากการใช้ลายเซ็น interface ได้
ความถูกต้องของพฤติกรรม
- การทดสอบแบบจำลองช่วยให้การทดสอบระบบกระจายทำได้ง่ายขึ้น และสามารถใช้โครงสร้างของพฤติกรรม
gen_server เพื่อทำให้การแก้ปัญหาง่ายขึ้น
การมีส่วนร่วม
- มีแนวคิดอย่างการหยิบยืมไอเดียจากงานของ Martin Thompson เพื่อสร้าง event loop ที่รวดเร็ว และเพิ่ม asynchronous I/O เป็นต้น
- หากสนใจ หรือมีความคิดเห็น ข้อเสนอแนะ หรือคำถาม ก็สามารถติดต่อได้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สิ่งที่น่าทึ่งเกี่ยวกับ Erlang และ BEAM คือความลึกของความสามารถ สำหรับผู้เขียนต้นฉบับ สิ่งที่ได้ประโยชน์มากที่สุดคือ Behavior/Interface ของ Erlang ส่วนตัวคิดว่าประเด็นสำคัญคือทรัพยากรการพัฒนาที่จำเป็นต่อการสร้างระบบซับซ้อนนั้นน้อยกว่าภาษาอื่นมาก สำหรับหลายคน จุดดึงดูดคือ lightweight process และโมเดลการเขียนโปรแกรม
eiของ Erlang เพื่อคอมไพล์โหนดจาก C และเชื่อมต่อกับ Erlang node อื่น ๆ ได้ ผ่านไลบรารีrpcของ Erlang จึงสามารถเรียกฟังก์ชันจาก C และเชื่อมต่อกับแอปพลิเคชัน Elixir ได้เคยทำงานกับผู้จัดการบางคนและคนที่อยากเขียนหนังสือจากประสบการณ์ของตัวเอง เรามักเห็นไม่ตรงกันเสมอเกี่ยวกับปัจจัยแห่งความสำเร็จ บางคนอ้างว่า lightweight process และ message passing ไม่ใช่เคล็ดลับสำคัญ แต่กลับมองข้ามว่า Communicating Sequential Processes ของ Erlang แยกออกจากคุณลักษณะเหล่านี้ไม่ได้
กลับมาสนใจ Erlang อีกครั้งเพราะ lightweight process และ message passing จนถึงตอนนี้ behavior ยังเป็นเรื่องรอง
กำลังหาข้อมูลว่าทำไม Ericsson ถึงเลิกใช้ Erlang และเรื่องการถูกไล่ออกของ Joe
พลังของ Erlang/Elixir ไม่ได้อยู่ที่การทำ Actor model, การ matching แบบ Prolog, immutability หรือ behavior แต่อยู่ที่ความมุ่งมั่นของ Joe ที่อยากพิสูจน์ว่าสามารถทำสิ่งต่าง ๆ ได้มากขึ้นด้วยทรัพยากรที่น้อยลง
Erlang, OTP และ BEAM ให้อะไรมากกว่า behavior ตัว VM คล้าย virtual kernel โดยมี supervisor, isolated process และ distributed mode ส่วน OTP ก็มีโมดูลที่มีประโยชน์ เช่น Mnesia (ฐานข้อมูล), atomic counter/ETS table (แคช) เป็นต้น
แนวคิดที่น่าสนใจที่สุดใน Erlang/BEAM คือการมี partial recovery ฝังมาเป็นค่าเริ่มต้น หากเกิดสถานะที่ไม่คาดคิด แทนที่จะปิดทั้งโปรเซสหรือเสี่ยงทำให้ระบบเสียหาย ก็จะ rollback กลับไปยังสถานะดีที่รู้แน่ชัดในระดับที่ละเอียดที่สุดเท่าที่เป็นไปได้
เหตุผลที่นักออกแบบภาษาและไลบรารีภาษาอื่นไม่ขโมยโครงสร้าง behavior ของ Erlang ไปใช้ ก็เพราะ function signature ของ behavior ใน Erlang เชื่อมโยงอย่างใกล้ชิดกับคุณสมบัติอื่นของ Erlang โดยเฉพาะการใช้ immutability ในแบบเฉพาะตัว
ไม่เห็นด้วยกับเนื้อหาในบทความนี้ behavior เกิดขึ้นได้เพราะสถาปัตยกรรมพื้นฐานของระบบ behavior ไม่ใช่อินเทอร์เฟซ แต่คล้ายกับ abstract object ในภาษาอย่าง Java มากกว่า
behavior ไม่ได้น่าสนใจขนาดนั้น มันมีอยู่ในภาษาโปรแกรมอื่นด้วย สิ่งที่น่าสนใจใน BEAM คือการ throw error ทำได้อย่างสง่างามมาก พลังของการ throw error ร่วมกับ behavior คือทำให้การจับข้อผิดพลาด การรายงานข้อมูล context และโดยทั่วไปการประกอบรวมกันนั้นทำได้ง่าย