ภาษาโปรแกรมมิ่ง Elixir ยังคงจุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนา โดยเฉพาะเรื่องระบบ dynamic typing และความพร้อมสำหรับองค์กร สร้างขึ้นบน Erlang Virtual Machine (BEAM) ที่ผ่านการทดสอบมาแล้ว Elixir ได้ดึงดูดความสนใจด้วยโมเดล concurrency ที่ทรงพลังและความสามารถในการทนต่อข้อผิดพลาด แต่นักพัฒนายังคงแบ่งแยกความคิดเห็นว่าการขาด static typing ขัดขวางการนำไปใช้ในโปรเจกต์ขนาดใหญ่หรือไม่
ความแตกแยกเรื่อง Static Typing
ประเด็นที่ถกเถียงกันมากที่สุดในหมู่นักพัฒนา Elixir คือระบบ dynamic typing ของภาษานี้ นักพัฒนาหลายคนที่เคยทำงานกับ Elixir ในเชิงอาชีพรายงานถึงความท้าทายด้านประสิทธิภาพอย่างมากเมื่อเข้าร่วมโปรเจกต์ที่มีอยู่แล้วหรือทำงานในทีมขนาดใหญ่ ปัญหาหลักอยู่ที่การทำความเข้าใจโค้ด - หากไม่มีข้อมูลประเภทที่ชัดเจน นักพัฒนาต้องใช้เวลามากในการติดตาม codebase เพื่อเข้าใจว่าฟังก์ชันต่างๆ คาดหวัง data type แบบไหนและส่งคืนอะไร
ความท้าทายนี้รุนแรงขึ้นโดยเฉพาะในสภาพแวดล้อมองค์กรที่หลายทีมทำงานร่วมกันใน codebase ขนาดใหญ่พร้อมการเปลี่ยนแปลงบุคลากรบ่อยครั้ง นักพัฒนาหลายคนสังเกตว่าแม้ Elixir จะมี type specifications (typespecs) แบบเสริมและเครื่องมือ Dialyzer ที่ให้ความช่วยเหลือบ้าง แต่ก็ยังห่างไกลจากการตรวจสอบประเภทข้อมูลแบบครอบคลุมที่มีในภาษาอย่าง TypeScript, Go หรือ Rust
ชุมชนได้ตอบสนองต่อข้อกังวลเหล่านี้ด้วย Gleam ซึ่งเป็นภาษาแบบ statically-typed ที่ทำงานบน BEAM virtual machine เดียวกันกับ Elixir Gleam เสนอประโยชน์ด้าน concurrency ของระบบนิเวศ Erlang พร้อมกับความปลอดภัยด้านประเภทข้อมูลที่นักพัฒนาหลายคนต้องการ อย่างไรก็ตาม ระบบนิเวศของ Gleam ยังคงไม่เป็นผู้ใหญ่เมื่อเปรียบเทียบกับไลบรารีและเฟรมเวิร์กที่ก่อตั้งขึ้นแล้วของ Elixir
Elixir เทียบกับภาษาอื่นๆ - คุณลักษณะหลัก
| คุณสมบัติ | Elixir | Go | TypeScript | Rust |
|---|---|---|---|---|
| ระบบการกำหนดประเภท | แบบไดนามิก (gradual typing ในระหว่างการพัฒนา) | แบบสแตติก | แบบสแตติก (มีการลบประเภทข้อมูลตอน runtime) | แบบสแตติก |
| โมเดลการทำงานพร้อมกัน | Actor model ด้วยกระบวนการที่มีน้ำหนักเบา | Goroutines | Event loop (Node.js) | Ownership model ด้วย async/await |
| การจัดการหน่วยความจำ | Garbage collected ต่อกระบวนการ | Garbage collected | Garbage collected | Zero-cost abstractions ไม่มี GC |
| ความทนทานต่อข้อผิดพลาด | Supervision trees ในตัว | การจัดการข้อผิดพลาดด้วยตนเอง | การจัดการข้อผิดพลาดด้วยตนเอง | ความปลอดภัยตอนคอมไพล์ |
| ความยากง่ายในการเรียนรู้ | ปานกลางถึงสูง | ต่ำถึงปานกลาง | ปานกลาง | สูง |
การยอมรับในองค์กรและความท้าทายในโลกแห่งความเป็นจริง
แม้จะมีข้อกังวลเรื่อง typing แต่ Elixir ก็ประสบความสำเร็จในการนำไปใช้งานที่โดดเด่นหลายแห่ง บริษัทอย่าง Nubank ธนาคารที่มีมูลค่าสูงที่สุดในละตินอเมริกา ได้ลงทุนอย่างมากในภาษานี้ แม้กระทั่งซื้อกิจการ Plataformatec บริษัทที่สร้าง Elixir ขึ้นมา BBC ก็ได้นำ Elixir มาใช้สำหรับระบบการผลิตในระดับใหญ่ แสดงให้เห็นถึงความเป็นไปได้สำหรับแอปพลิเคชันที่สำคัญต่อภารกิจ
อย่างไรก็ตาม เส้นทางสู่การยอมรับในองค์กรไม่ปราศจากอุปสรรค องค์กรบางแห่งประสบปัญหาในการรวม Elixir applications เข้ากับโครงสร้างพื้นฐานแบบ containerized สมัยใหม่และการ deploy บน Kubernetes แม้ว่าปรัชญา let it crash ของ Elixir และความสามารถในการจัดกลุ่มแบบ built-in อาจขัดแย้งกับรูปแบบการจัดการ container orchestration แต่ทีมที่มีประสบการณ์ก็สามารถ deploy Elixir applications ในสภาพแวดล้อม cloud-native ได้สำเร็จ
Phoenix LiveView ซึ่งเป็นเฟรมเวิร์กเว็บแบบ real-time ของ Elixir นำเสนอความท้าทายในการยอมรับอีกประการหนึ่ง แม้ว่าจะเสนอประสิทธิภาพการพัฒนาที่น่าประทับใจสำหรับการสร้างเว็บแอปพลิเคชันแบบโต้ตอบ แต่ลักษณะ stateful ของมันอาจทำให้กลยุทธ์การ deploy และการกู้คืนจากข้อผิดพลาดในระบบกระจายซับซ้อนขึ้น
บริษัทที่ใช้ Elixir ในการผลิต
- Nubank: ธนาคารที่มีมูลค่าสูงที่สุดในละตินอเมริกา ได้เข้าซื้อกิจการ Plataformatec (บริษัทผู้สร้าง Elixir )
- BBC: การใช้งานจริงขนาดใหญ่สำหรับบริการสื่อ
- Discord: ใช้ Elixir สำหรับโครงสร้างพื้นฐานการสื่อสารแบบเรียลไทม์ (ร่วมกับ Rust สำหรับส่วนประกอบที่ต้องการประสิทธิภาพสูง)
- WhatsApp: ใช้ Erlang (VM เดียวกันกับ Elixir ) สำหรับโครงสร้างพื้นฐานการส่งข้อความ
- Transport.data.gouv.fr: จุดเข้าถึงข้อมูลการขนส่งแห่งชาติของฝรั่งเศส ดำเนินการมาตั้งแต่ปี 2016
ข้อได้เปรียบด้าน Concurrency
จุดที่ Elixir เปล่งประกายอย่างแท้จริงคือแนวทางการจัดการ concurrency และการทนต่อข้อผิดพลาด actor model ของภาษาที่สืบทอดมาจาก Erlang ช่วยให้นักพัฒนาสามารถสร้าง lightweight processes หลายล้านตัวที่สื่อสารผ่านการส่งข้อความ การออกแบบนี้ทำให้เหมาะสมเป็นพิเศษสำหรับแอปพลิเคชันที่ต้องการ concurrency สูง เช่น ระบบแชท แพลตฟอร์ม IoT และเว็บแอปพลิเคชันแบบ real-time
ประสบการณ์ทั้งสองแตกต่างกันอย่างสิ้นเชิง ในขณะที่ฉันชอบความเร็วในการพัฒนาที่ยอดเยี่ยมสำหรับโปรเจกต์ส่วนตัว ที่ฉันเขียนโค้ดมากกว่าอ่าน การเข้าร่วมโปรเจกต์ที่มีอยู่แล้วต้องการสิ่งตรงกันข้าม คือ อ่านโค้ดมากกว่าเขียน
ปรัชญา let it crash แม้ว่าบางครั้งจะถูกเข้าใจผิด แต่ให้รากฐานที่แข็งแกร่งสำหรับการสร้างระบบที่ยืดหยุ่น เมื่อ process แต่ละตัวล้มเหลว มันสามารถถูกเริ่มใหม่โดย supervisors โดยไม่ส่งผลกระทบต่อส่วนที่เหลือของแอปพลิเคชัน แนวทางนี้ได้พิสูจน์คุณค่าโดยเฉพาะในระบบโทรคมนาคมและระบบสำคัญอื่นๆ ที่ uptime เป็นสิ่งสำคัญยิ่ง
เครื่องมือและทางเลือกในระบบนิเวศ Elixir
เครื่องมือหลัก:
- Phoenix: เว็บเฟรมเวิร์กที่คล้ายกับ Ruby on Rails
- LiveView: แอปพลิเคชันเว็บแบบเรียลไทม์โดยไม่ต้องใช้ JavaScript
- OTP (Open Telecom Platform): ไลบรารีที่ผ่านการทดสอบมาแล้วสำหรับสร้างระบบแบบกระจาย
- Dialyzer: เครื่องมือวิเคราะห์แบบสแตติกเสริมสำหรับตรวจสอบประเภทข้อมูล
ทางเลือกบน BEAM VM:
- Gleam: ภาษาที่มีการกำหนดประเภทข้อมูลแบบสแตติกพร้อมความสามารถในการทำงานร่วมกับ Elixir
- Erlang: ภาษาต้นฉบับที่มีระดับต่ำกว่าแต่มีความมั่นคงมากกว่า
- LFE (Lisp Flavoured Erlang): ไวยากรณ์ Lisp บน BEAM VM
 |
|---|
| เครื่องเปรียบเทียบเชิงอุปมาสำหรับแง่มุมที่เปลี่ยนแปลงได้และมีสีสันของโมเดลการทำงานพร้อมกันของ Elixir ซึ่งสะท้อนถึงศักยภาพและความคิดสร้างสรรค์ภายในภาษานี้ |
มองไปข้างหน้า
ทีม Elixir core ได้รับทราบข้อกังวลเรื่อง typing และกำลังทำงานอย่างแข็งขันเกี่ยวกับฟีเจอร์ gradual typing เวอร์ชันล่าสุดของภาษารวมถึง set-theoretic types และการตรวจสอบประเภทข้อมูลแบบ compile-time ที่ปรับปรุงแล้ว แม้ว่าฟีเจอร์เหล่านี้ยังคงพัฒนาอยู่ เป้าหมายคือการให้ static typing แบบเสริมที่ไม่ประนีประนอมลักษณะ dynamic หรือความยืดหยุ่นด้าน runtime ของภาษา
สำหรับองค์กรที่พิจารณา Elixir การตัดสินใจมักจะขึ้นอยู่กับความเชี่ยวชาญของทีมและความต้องการของโปรเจกต์ ทีมเล็กที่ทำงานกับแอปพลิเคชันที่เน้น I/O และมีความต้องการแบบ real-time อาจพบว่าประโยชน์ด้านประสิทธิภาพของ Elixir มีน้ำหนักมากกว่าข้อกังวลเรื่อง typing องค์กรขนาดใหญ่ที่มีทีมพัฒนาหลากหลายอาจชอบตาข่ายนิรภัยของทางเลือกแบบ statically-typed แม้ว่าพวกเขาอาจต้องสร้างโซลูชันของตัวเองสำหรับฟีเจอร์ concurrency และ fault-tolerance ที่ Elixir ให้มาแบบ out of the box
การถกเถียงที่กำลังดำเนินอยู่สะท้อนแนวโน้มที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ ที่ทีมต้องสร้างสมดุลระหว่างประสิทธิภาพนักพัฒนา ความสามารถในการบำรุงรักษาโค้ด และความน่าเชื่อถือของระบบ ขณะที่ Elixir ยังคงพัฒนาและเป็นผู้ใหญ่ ความสำเร็จของมันจะขึ้นอยู่กับว่ามันจัดการกับข้อกังวลที่แข่งขันกันเหล่านี้ได้ดีเพียงใด ในขณะที่รักษาข้อได้เปรียบเฉพาะที่ทำให้มันน่าสนใจสำหรับกรณีการใช้งานบางอย่าง
อ้างอิง: #0181: Why Elixir? A Rebuttal to Common Misconceptions