1 คะแนน โดย GN⁺ 2025-04-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ภูมิหลัง

  • 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 ความคิดเห็น

 
GN⁺ 2025-04-13
ความคิดเห็นบน Hacker News
  • สิ่งที่น่าทึ่งเกี่ยวกับ Erlang และ BEAM คือความลึกของความสามารถ สำหรับผู้เขียนต้นฉบับ สิ่งที่ได้ประโยชน์มากที่สุดคือ Behavior/Interface ของ Erlang ส่วนตัวคิดว่าประเด็นสำคัญคือทรัพยากรการพัฒนาที่จำเป็นต่อการสร้างระบบซับซ้อนนั้นน้อยกว่าภาษาอื่นมาก สำหรับหลายคน จุดดึงดูดคือ lightweight process และโมเดลการเขียนโปรแกรม

    • OTP มีฟังก์ชันจำนวนมากมาก เรากำลังทำงานคอมไพล์ให้ Elixir สามารถรันบนอุปกรณ์ iOS ได้ โดยใช้ไลบรารี ei ของ Erlang เพื่อคอมไพล์โหนดจาก C และเชื่อมต่อกับ Erlang node อื่น ๆ ได้ ผ่านไลบรารี rpc ของ Erlang จึงสามารถเรียกฟังก์ชันจาก C และเชื่อมต่อกับแอปพลิเคชัน Elixir ได้
    • Erlang ได้แก้ปัญหาหลายอย่างที่เทคสแต็กสมัยใหม่ยังดิ้นรนอยู่ และได้จัดการปัญหาเรื่อง scalability กับต้นทุนการพัฒนาไว้ตั้งแต่หลายสิบปีก่อนแล้ว แต่ใน HN ความสนใจต่อ Erlang/Elixir ไม่ได้นำไปสู่การใช้งานจริง และหลายบริษัทก็กำลังเสียเงินไปกับการพยายามสร้างสิ่งที่มีให้ฟรีอยู่แล้วในสแต็ก Erlang
  • เคยทำงานกับผู้จัดการบางคนและคนที่อยากเขียนหนังสือจากประสบการณ์ของตัวเอง เรามักเห็นไม่ตรงกันเสมอเกี่ยวกับปัจจัยแห่งความสำเร็จ บางคนอ้างว่า lightweight process และ message passing ไม่ใช่เคล็ดลับสำคัญ แต่กลับมองข้ามว่า Communicating Sequential Processes ของ Erlang แยกออกจากคุณลักษณะเหล่านี้ไม่ได้

    • ตัวอย่าง: โปรแกรมเมอร์ฝั่งแอปพลิเคชันเขียนโค้ดแบบลำดับ และความพร้อมกันทั้งหมดถูกซ่อนไว้ใน behavior
    • สมาชิกทีมใหม่เริ่มงานได้ง่าย: business logic เป็นแบบลำดับ และเป็นโครงสร้างที่อาจเคยเห็นมาก่อน
    • supervisor และแนวคิด "ปล่อยให้พัง" มีส่วนช่วยสร้างระบบที่เชื่อถือได้
  • กลับมาสนใจ Erlang อีกครั้งเพราะ lightweight process และ message passing จนถึงตอนนี้ behavior ยังเป็นเรื่องรอง

    • โปรเจ็กต์นี้คือการนำ visual Flow Based Programming (FBP) มาสู่ Erlang โดย FBP ดูจะเข้ากับ Erlang ได้ดี และก็น่าแปลกใจที่มีสิ่งนี้อยู่แล้ว
    • กำลังใช้ Node-RED เป็นเครื่องมือสำหรับ FBP และแนวคิดหลักคือเชื่อมฟรอนต์เอนด์ของ Node-RED เข้ากับแบ็กเอนด์ Erlang และทำให้ทุกโหนดเป็นโปรเซส
  • กำลังหาข้อมูลว่าทำไม Ericsson ถึงเลิกใช้ Erlang และเรื่องการถูกไล่ออกของ Joe

    • คำตอบสั้น ๆ คือ Erlang ถูกกันออกไปเมื่อมีการเปลี่ยนไปใช้ Java สำหรับโปรเจ็กต์ใหม่ Joe และเพื่อนร่วมงานก่อตั้ง Bluetail ในปี 1998 และต่อมาถูก Nortel เข้าซื้อ Nortel เป็นยักษ์ใหญ่ด้านโทรคมนาคม โดยราคาหุ้นขึ้นไปถึง $125 ในปี 2000 แต่ตกลงมาต่ำกว่า $1 ในปี 2002 ซึ่งเกี่ยวข้องกับการแตกของฟองสบู่ดอตคอมและการใช้จ่ายด้านโทรคมนาคมที่ลดลง
  • พลังของ 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 (แคช) เป็นต้น

    • เมื่อ 1 ปีก่อน ได้เลือกใช้ Erlang เป็นภาษาแบ็กเอนด์ในบริษัทที่ปรึกษาส่วนตัว โดยได้สำรวจภายในของ BEAM เพื่อเปลี่ยนสแต็กที่อิง TCP เป็น QUIC และรวมแพตช์ Rust เข้าไป
  • แนวคิดที่น่าสนใจที่สุดใน Erlang/BEAM คือการมี partial recovery ฝังมาเป็นค่าเริ่มต้น หากเกิดสถานะที่ไม่คาดคิด แทนที่จะปิดทั้งโปรเซสหรือเสี่ยงทำให้ระบบเสียหาย ก็จะ rollback กลับไปยังสถานะดีที่รู้แน่ชัดในระดับที่ละเอียดที่สุดเท่าที่เป็นไปได้

  • เหตุผลที่นักออกแบบภาษาและไลบรารีภาษาอื่นไม่ขโมยโครงสร้าง behavior ของ Erlang ไปใช้ ก็เพราะ function signature ของ behavior ใน Erlang เชื่อมโยงอย่างใกล้ชิดกับคุณสมบัติอื่นของ Erlang โดยเฉพาะการใช้ immutability ในแบบเฉพาะตัว

    • ถ้าจะให้ได้เป้าหมายเดียวกันในภาษาอื่น ก็ไม่ควรคัดลอกแนวทางของ Erlang ตรง ๆ แนะนำให้เรียนรู้จากซอฟต์แวร์ที่เชื่อถือได้ของ Erlang แต่คัดค้านอย่างยิ่งกับการพอร์ตแนวทางของ Erlang ไปยังภาษาอื่นแบบทั้งดุ้น
  • ไม่เห็นด้วยกับเนื้อหาในบทความนี้ behavior เกิดขึ้นได้เพราะสถาปัตยกรรมพื้นฐานของระบบ behavior ไม่ใช่อินเทอร์เฟซ แต่คล้ายกับ abstract object ในภาษาอย่าง Java มากกว่า

    • งานเขียนของ Joe แสดงให้เห็นวิธีสร้างระบบที่เชื่อถือได้โดยใช้ชุดบล็อกเลโก้ที่มีอยู่
  • behavior ไม่ได้น่าสนใจขนาดนั้น มันมีอยู่ในภาษาโปรแกรมอื่นด้วย สิ่งที่น่าสนใจใน BEAM คือการ throw error ทำได้อย่างสง่างามมาก พลังของการ throw error ร่วมกับ behavior คือทำให้การจับข้อผิดพลาด การรายงานข้อมูล context และโดยทั่วไปการประกอบรวมกันนั้นทำได้ง่าย