ชุมชนนักเขียนโปรแกรมกำลังมีอภิปรายที่น่าสนใจเกี่ยวกับแนวทางการนำ OTP (Open Telecom Platform) ของ Gleam ที่ใช้ static typing ขณะที่นักพัฒนากำลังสำรวจภาษาเกิดใหม่ที่คอมไพล์ไปยัง BEAM (Bogdan/Björn's Erlang Abstract Machine) นี้ คำถามก็เกิดขึ้นว่าการใช้ static typing นั้นช่วยเสริมหรือทำให้ระบบทนต่อข้อผิดพลาดอันเลื่องชื่อที่ Erlang ทำให้สมบูรณ์แบบมาหลายทศวรรษนั้นซับซ้อนขึ้น
Gleam ซึ่งเป็นภาษา functional ที่ใช้ static typing ได้รับความสนใจจากไวยากรณ์ที่สะอาดตาและความปลอดภัยด้านประเภทข้อมูล ในขณะที่ยังคงความเข้ากันได้กับระบบนิเวศของ Erlang การโฟกัสไปที่การนำ OTP ไปใช้ล่าสุดได้เผยให้เห็นทั้งความตื่นเต้นและความสงสัยภายในชุมชนนักพัฒนา
การแลกเปลี่ยนกับความปลอดภัยของประเภทข้อมูล
การนำ OTP ไปใช้ของ Gleam ให้ความสำคัญกับความปลอดภัยของประเภทข้อมูลแบบเต็มรูปแบบสำหรับ actors และ messages สร้างประสบการณ์ที่แตกต่างโดยพื้นฐานจากการพัฒนา Erlang แบบดั้งเดิม แม้แนวทางนี้จะดึงดูดนักพัฒนาที่มาจากภาษาในตระกูล ML เช่น Haskell และ F# แต่ก็มาพร้อมกับข้อจำกัด โดยปัจจุบันไลบรารี OTP ของ Gleam ยังไม่รองรับฟังก์ชันการทำงานทั้งหมดของ Erlang / OTP โดยเฉพาะฟีเจอร์ที่ท้าทายในการแสดงในรูปแบบที่ปลอดภัยประเภท ข้อความระบบบางส่วนถูกทิ้งโดย actors ไปอย่างง่ายดาย และ API การดีบักบางส่วนอาจทำงานไม่เต็มที่
ความคิดที่ว่า static typing เป็นปัญหาใหญ่สำหรับเซิร์ฟเวอร์และระบบส่งข้อความสไตล์ OTP นั้นเป็นตำนานที่ยืนยงมากๆ ด้วยความจริงใจ ฉันสร้างเลเยอร์บางๆ บน OTP สำหรับทั้ง purerl และ Gleam ที่ลงเอยด้วยทั้งอินเทอร์เฟซที่ปลอดภัยประเภทและปลอดภัยประเภทภายใน
มุมมองนี้เน้นย้ำถึงการอภิปรายที่กำลังดำเนินอยู่เกี่ยวกับว่าธรรมชาติแบบไดนามิกของ OTP นั้นเป็นฟีเจอร์หรือข้อจำกัด ผู้สนับสนุน static typing ให้เหตุผลว่ามันทำให้การปรับโครงสร้างโค้ดใหม่ทำได้โดยไม่กลัวและตรวจจับข้อผิดพลาดได้ในเวลาคอมไพล์ ในขณะที่นักพัฒนา BEAM แบบดั้งเดิมให้คุณค่ากับความยืดหยุ่นขณะรันไทม์ที่ขับเคลื่อนระบบที่น่าเชื่อถือที่สุดในโลกบางระบบ
สถานะการพัฒนา Gleam OTP
-
ฟีเจอร์ที่รองรับ:
- actors และ messages ที่มีความปลอดภัยด้านประเภทข้อมูล
- การดูแล process ขั้นพื้นฐาน
- ความเข้ากันได้กับเฟรมเวิร์ก OTP ของ Erlang
- ความทนทานต่อข้อผิดพลาดผ่าน supervisors
-
ข้อจำกัดในปัจจุบัน:
- ยังไม่รองรับข้อความระบบ OTP ทั้งหมด
- API สำหรับการดีบักบางตัวอาจทำงานไม่ครบถ้วน
- ไลบรารี gleam_otp อยู่ในสถานะทดลอง
- ไม่รองรับ named processes
- กลยุทธ์ supervisor มีจำนวนจำกัดเมื่อเทียบกับ OTP แบบเต็มรูปแบบ
เส้นทางการเรียนรู้และความสมบูรณ์ของระบบนิเวศ
การอภิปรายเผยให้เห็นถึงความแตกแยกที่ชัดเจนในแนวทางการเรียนรู้ที่แนะนำสำหรับผู้มาใหม่ในโลก BEAM นักพัฒนาที่มีประสบการณ์หลายคนแนะนำให้เริ่มต้นด้วย Elixir หรือแม้แต่ Erlang ดิบเพื่อทำความเข้าใจพื้นฐาน OTP ก่อนที่จะไปสำรวจ Gleam เหตุผลนั้นตรงไปตรงมา: Elixir และ Erlang มีเอกสารประกอบที่ครอบคลุมกว่า เครื่องมือที่สมบูรณ์ และรูปแบบที่ได้รับการยอมรับสำหรับการสร้างระบบกระจาย
นักพัฒนาคนหนึ่งแบ่งปันประสบการณ์ของพวกเขา: ฉันมักพบว่าตัวเองอ้างอิงเอกสารของ Elixir แล้ว 'แปล' ความรู้นั้นไปเป็นการนำ OTP ไปใช้ของ Gleam รูปแบบนี้ดูเหมือนจะเป็นเรื่องปกติในกลุ่มผู้ใช้ Gleam รุ่นแรกๆ ที่ชื่นชอบระบบประเภทของภาษาแต่จำเป็นต้องเชื่อมช่องว่างความรู้โดยใช้ทรัพยากร BEAM ที่มีความเป็นมาอย่างมาก
การพิจารณาระบบนิเวศมีความสำคัญอย่างยิ่งสำหรับการพัฒนาเว็บ ขณะที่เฟรมเวิร์ก Phoenix ของ Elixir ผ่านการทดสอบในสนามรบและสมบูรณ์พร้อมด้วยฟีเจอร์ เรื่องการพัฒนาเว็บของ Gleam เกี่ยวข้องกับการรวมไลบรารีขนาดเล็กหลายตัวเข้าด้วยกัน เช่น Lustre สำหรับ front-end, Wisp สำหรับเซิร์ฟเวอร์ และ Squirrel สำหรับการโต้ตอบกับฐานข้อมูล แนวทางแบบโมดูลาร์นี้เสนอความยืดหยุ่นแต่ต้องการงานบูรณาการมากขึ้นเมื่อเทียบกับปรัชญาแบบรวมทุกอย่างไว้ในตัวของ Phoenix
การเปรียบเทียบภาษา BEAM สำหรับการพัฒนา OTP
| ด้าน | Erlang | Elixir | Gleam |
|---|---|---|---|
| ความยากง่ายในการเรียนรู้ | ยาก ชัดเจน | ปานกลาง ไวยากรณ์คล้าย Ruby | ปานกลาง ไวยากรณ์คล้าย ML |
| เอกสาร OTP | ครอบคลุมสมบูรณ์ | กว้างขวาง | จำกัด กำลังเติบโต |
| ระบบ Type | Dynamic | Dynamic | Static |
| ความเป็นผู้ใหญ่ของ Ecosystem | เป็นผู้ใหญ่มาก | เป็นผู้ใหญ่ | กำลังเกิดขึ้น |
| Web Framework | มีตัวเลือกหลากหลาย | Phoenix (เป็นผู้ใหญ่) | Lustre + Wisp (แบบโมดูล) |
| ความพร้อมใช้งานจริง | ผ่านการทดสอบในสนามรบ | ผ่านการทดสอบในสนามรบ | ทดลองสำหรับ OTP |
กรณีการใช้งานในระบบผลิตและกลยุทธ์การบูรณาการ
ที่น่าสนใจคือ บางทีมกำลังหาวิธีสร้างสรรค์ในการบูรณาการ Gleam เข้ากับระบบที่มีอยู่โดยไม่ต้องผูกมัดกับภาษานั้นอย่างเต็มที่ หัวหน้าทีมคนหนึ่งอธิบายแนวทางแบบค่อยเป็นค่อยไปของพวกเขา: พวกเรากำลังดันแพตเทิร์น 'functional core, imperative shell' ไปสู่ขีดสุดของมาโคร และให้ Gleam รับงานพื้นหลังจาก codebases Ruby on Rails ที่มีอยู่ของเราในส่วนที่เรามีงานคำนวณหนัก
กลยุทธ์นี้ใช้จุดแข็งของ Gleam ในตรรกะธุรกิจที่ปลอดภัยประเภท ในขณะที่พึ่งพาระบบนิเวศที่สมบูรณ์กว่าสำหรับอินเทอร์เฟซเว็บและ HTTP API มันแสดงให้เห็นเส้นทางการนำไปใช้แบบเน้นปฏิบัติการจริงที่ไม่จำเป็นต้องละทิ้งการลงทุนที่มีอยู่ในเทคโนโลยีอื่นๆ
การสนทนายังกล่าวถึงความท้าทายในการทำงานร่วมกัน นักพัฒนาหลายคนระบุว่างาน FFI (Foreign Function Interface) ระหว่าง Gleam และ Erlang อาจเป็นเรื่องยุ่งยาก โดยเฉพาะเมื่อต้องจัดการกับโครงสร้างข้อมูล Erlang ที่ซับซ้อนซึ่งไม่สามารถจับคู่กับระบบประเภทของ Gleam ได้อย่างสะอาดตา จุดเสียดทานนี้ชี้ให้เห็นว่าในขณะที่ Gleam เก่งกาจในโค้ด Gleam ล้วนๆ การบูรณาการกับ codebases Erlang/Elixir ที่มีอยู่จำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ
อนาคตของภาษา BEAM ที่มีประเภทข้อมูล
การอภิปรายที่กำลังดำเนินอยู่สะท้อนให้เห็นแนวโน้มกว้างๆ ในการออกแบบภาษาโปรแกรม ซึ่งนักพัฒนากำลังแสวงหาความน่าเชื่อถือของ static typing มากขึ้นโดยไม่เสียสละประโยชน์ด้านการทำงานพร้อมกันและความทนต่อข้อผิดพลาดที่ทำให้ Erlang มีชื่อเสียง ในขณะที่ Gleam เป็นตัวแทนของแนวทางหนึ่งในการท้าทายนี้ โครงการอื่นๆ เช่น Purerl (PureScript ที่คอมไพล์ไปยัง Erlang) กำลังสำรวจพื้นที่ที่คล้ายกัน
เมื่อระบบนิเวศเติบโตเต็มที่ คำถามสำคัญยังคงอยู่: ภาษา BEAM ที่มี static typing จะสามารถบรรลุระดับความน่าเชื่อถือและประสิทธิภาพที่ทำให้ระบบ Erlang มีชื่อเสียงในการบรรลุ uptime เก้านาย (99.9999999%) ในแอปพลิเคชันโทรคมนาคมได้หรือไม่? ชุมชนดูเหมือนจะแบ่งออกเป็นสองฝ่าย โดยบางส่วนมองว่า static typing เป็นสิ่งจำเป็นสำหรับระบบขนาดใหญ่ที่สามารถบำรุงรักษาได้ ในขณะที่คนอื่นๆ มองว่ามันอาจทำให้ความเรียบง่ายแต่สง่างามที่ทำให้ OTP ประสบความสำเร็จนั้นซับซ้อนขึ้น
การพัฒนา Gleam และภาษาที่คล้ายกันชี้ให้เห็นว่าระบบนิเวศ BEAM กำลังวิวัฒนาการเพื่อรองรับปรัชญาการเขียนโปรแกรมที่แตกต่างกัน ในขณะที่ยังคงหลักการหลักที่ทำให้มันประสบความสำเร็จ ไม่ว่าสิ่งนี้จะแสดงถึงความแตกแยกหรือความหลากหลายที่ดีนั้นน่าจะขึ้นอยู่กับมุมมองและกรณีการใช้งานเฉพาะของแต่ละคน
อ้างอิง: Gleam OTP