ล่ามจำนวนมากและรันไทม์ของภาษาการเขียนโปรแกรม Ruby

บทนำ

เช่นเดียวกับที่มีทับทิมเจมหลายเฉด ล่าม Ruby ก็มีการนำไปใช้งานหลายอย่างเช่นกัน

ล่าม Ruby ที่ใช้กันมากที่สุดคือการใช้งานอ้างอิง Ruby MRI ซึ่งพัฒนาขึ้นในภาษา C โดยผู้สร้าง Ruby (Yukihiro Matsumoto) และทีมงานหลักของ Ruby

คู่มือการจ้างงาน Ruby on Rails ของเราระบุว่าข้อเสียบางประการใน Rails สามารถแก้ไขได้หรือหลีกเลี่ยงโดยใช้ตัวแปล Ruby สำรอง บทความนี้แสดงการใช้งานและรันไทม์ของล่าม Ruby ที่มีอยู่ในปัจจุบัน โดยกล่าวถึงข้อดีและข้อเสียของแต่ละรายการ

ประวัติเวอร์ชันทับทิม (และผลกระทบต่อการใช้งานทางเลือก)

น่าเศร้าที่ไม่มีการอ้างอิงภาษา Python สำหรับ Ruby เทียบเท่า (ISO/IEC 30170:2012 อธิบาย Ruby 1.8 / Ruby 1.9 แต่ไม่มีข้อมูลจำเพาะที่เกี่ยวข้องสำหรับ Ruby 2.x) ในกรณีที่ไม่มีข้อกำหนดภาษาดังกล่าว ตัวดำเนินการ Ruby มักจะอาศัย RubySpec ที่ขับเคลื่อนโดยชุมชนแทน ซึ่งระบุลักษณะการทำงานที่คาดหวังของภาษา Ruby ผ่านการทดสอบที่สามารถเรียกใช้ในล่าม Ruby ใดๆ ก็ได้ ดังนั้น RubySpec จึงถูกใช้โดยผู้ดำเนินการ Ruby เพื่อตรวจสอบการปฏิบัติตามพฤติกรรมของการนำ Ruby ไปใช้งานด้วยมาตรฐานโดยพฤตินัย

เนื่องจากไม่มีข้อกำหนดที่เป็นทางการ เวอร์ชันใหม่ของ Ruby มักจะสอดคล้องกับ Ruby MRI ที่ออกใหม่ เป็นที่น่าสังเกตว่ามีปัญหาเปิดที่กล่าวถึงขั้นตอนการออกแบบสำหรับการถอดรหัส Ruby (ภาษา) จาก Ruby MRI

ด้วยความสัมพันธ์ที่แน่นแฟ้นในปัจจุบัน แม้ว่าระหว่างภาษา Ruby และการนำการอ้างอิง MRI ไปใช้ นักพัฒนาของการใช้งาน Ruby สำรองบางครั้งพยายามดิ้นรนเพื่อให้ทันกับการเปลี่ยนแปลงภาษาที่นำมาใช้ในการเปิดตัว MRI ใหม่แต่ละครั้ง

ไม่เคยยากไปกว่านี้ในช่วงการเปลี่ยนผ่านระหว่าง Ruby 1.8 และ Ruby 1.9 ในปี 2550 ในความพยายามที่จะล้างและรวมไวยากรณ์ของ Ruby (ในขณะที่ภาษามีการพัฒนาในทศวรรษนับตั้งแต่เปิดตัว Ruby 1.0) ทีมงานหลักของ Ruby ได้เผยแพร่ Ruby 1.9.0 ซึ่งเป็นเวอร์ชันที่นำความไม่ลงรอยกันแบบย้อนหลัง จำนวนมาก ในภาษา . ด้วยเหตุนี้ การใช้งาน Ruby ทั้งหมดจึงไม่ได้ทุ่มเทความพยายามที่จำเป็นในการทำให้วากยสัมพันธ์กระโดดจาก 1.8 เป็น 1.9 ดังนั้นจึงมีการนำ Ruby แบบ 1.8 ไปใช้หลายตัวที่ไม่ได้ใช้โดยชุมชนอีกต่อไป แต่คุณอาจยังพบเห็นทางออนไลน์หรือได้รับการพูดคุยถึงโดยมือเก่าของ Ruby

Ruby MRI เวอร์ชันใหม่จะออกทุกๆ คริสต์มาสตามหลักการการกำหนดเวอร์ชันเชิงความหมาย Ruby 2.0 (วางจำหน่ายปี 2013) และ 2.1 (เปิดตัวในปี 2014) ต่างก็นำเสนอฟีเจอร์ภาษาเพิ่มเติมที่นักพัฒนา Ruby สามารถใช้ประโยชน์ได้ โดยไม่สูญเสียความเข้ากันได้แบบย้อนหลังกับ Ruby 1.9

เหตุใดจึงต้องใช้ Ruby ทางเลือกอื่น มีอะไรผิดปกติกับ MRI?

มีการใช้งาน Ruby ทางเลือกที่หลากหลาย รองรับกรณีการใช้งานและสภาพแวดล้อมที่หลากหลาย สภาพแวดล้อม Java Enterprise แอปพลิเคชั่นมือถือ การใช้งานจาวาสคริปต์ เครื่อง CPU/RAM ต่ำ นอกจากการรองรับกรณีการใช้งานเหล่านี้แล้ว บางครั้งการใช้งานทางเลือกยังช่วยเพิ่มความเร็วหรือการใช้หน่วยความจำได้อย่างมีประสิทธิภาพมากขึ้นในบางครั้ง ขึ้นอยู่กับลักษณะของแอปพลิเคชันของคุณ

เป็นเวลานานนักพัฒนา Ruby on Rails หลายคนใช้ Ruby Enterprise Edition (REE) แทน MRI โดยใช้ประโยชน์จากเทคนิคการจัดการหน่วยความจำที่ดีกว่าใน REE เมื่อเทียบกับเวอร์ชัน MRI ในขณะนั้น (REE ถูกยกเลิกในเวลาต่อมาแม้ว่าในปี 2555)

แม้ว่า MRI จะเป็นการนำ Ruby เริ่มต้นไปใช้ แต่ก็ไม่ใช่ตัวเลือกที่ถูกต้องสำหรับสภาพแวดล้อมและสถานการณ์ทั้งหมด ตัวอย่างเช่น การสนับสนุนการทำงานพร้อมกันของ MRI นั้นด้อยกว่า JRuby หรือ Rubinius นอกจากนี้ แม้ว่ารูปแบบหน่วยความจำและการรวบรวมขยะของ MRI จะได้รับการปรับปรุงอย่างต่อเนื่อง แต่ก็ยังมีปัญหาอยู่บ้าง

แบบสำรวจการใช้งาน Ruby ที่ตามมามีจุดมุ่งหมายเพื่อช่วยคุณในการเลือกล่ามที่เหมาะสมกับเป้าหมายการดำเนินงานและข้อจำกัดของโครงการของคุณมากที่สุด

Matz's Ruby Interpreter (MRI) / CRuby

เขียนเป็นภาษาซีโดยทีมงานหลักของ Ruby ที่นำโดย Yukihiro Matsumoto (“Matz” ผู้สร้าง Ruby) MRI เป็นการนำ Ruby ไปใช้อ้างอิงซึ่งทำหน้าที่เป็นมาตรฐานโดยพฤตินัย ตัวอย่างเช่น หากผู้จำหน่ายระบบปฏิบัติการมีเวอร์ชันของ Ruby เป็นส่วนหนึ่งของซอฟต์แวร์ที่ติดตั้งระบบปฏิบัติการ โดยปกติแล้วจะเป็นเวอร์ชัน MRI MRI ได้ประโยชน์จากสมาชิกในทีมหลักที่ได้รับค่าตอบแทนมากกว่าการนำ Ruby ไปใช้ รวมถึงทรัพยากรที่ได้รับการสนับสนุนโดยเฉพาะจากบุคคลหรือบริษัทที่ต้องการปรับปรุงระบบนิเวศของ Ruby

Ruby MRI เวอร์ชันใหม่ ซึ่งมักใช้คุณลักษณะภาษาใหม่ นอกเหนือจากการเปลี่ยนแปลงไลบรารีมาตรฐาน จะเผยแพร่ทุกคริสต์มาส ฟีเจอร์ต่างๆ จะถูกนำไปใช้ใน Ruby MRI ก่อน โดยปกติแล้วจะอิงตามการสนทนาเกี่ยวกับรายชื่อส่งเมลสำหรับนักพัฒนาหลักของ Ruby การใช้งาน Ruby อื่นๆ ล่าช้า ในบางกรณีอาจถึงแม้จะนานหลายปี

เจรูบี้

JRuby เป็นเวอร์ชันของ Ruby ที่ใช้งานบน Java Virtual Machine (JVM) เนื่องจากมันเป็นที่นิยมสำหรับภาษาที่นอกเหนือไปจาก Java ที่จะทำงานบน JVM (ฉันกำลังมองไปในทิศทางของคุณ, Clojure และ Scala) การนำ Ruby ที่ใช้ JVM ไปใช้มีแนวโน้มที่จะได้รับความนิยม

Ruby ใน JVM ยังหมายความว่า Ruby สามารถเรียกใช้ได้ทุกที่ที่ Java เรียกใช้ได้ (เช่น โทรศัพท์ Android โดยใช้ Ruboto เป็นต้น) นอกจากนี้ ด้วยความสามารถในการทำงานร่วมกันของ JVM โค้ด JRuby สามารถใช้แพลตฟอร์ม Java ได้ ซึ่งรวมถึงไลบรารีมาตรฐานและไลบรารีของบุคคลที่สาม

JRuby ยังมีประโยชน์ในการนำโซลูชันที่ใช้ Rails มาใช้ในสภาพแวดล้อมการปรับใช้ Java เท่านั้น บรรจุแอป Rails เป็นไฟล์ .war เพื่อปรับใช้กับคอนเทนเนอร์ Tomcat หรือเป็นแอปเพล็ต Java ที่ทำงานโดยเป็นส่วนหนึ่งของส่วนหน้าของเว็บของคุณ , ตัวอย่างเช่น.

สำหรับผู้ที่ไม่คุ้นเคยกับ JVM นั้น JRuby นำเสนอปัญหาที่เกี่ยวข้องกับ JVM มาตรฐาน เช่น การเริ่มทำงานช้าของล่าม Ruby การดีบักปัญหา CLASSPATH หากคุณใช้ไลบรารี Java บุคคลที่สาม การใช้หน่วยความจำที่ใหญ่ขึ้น และความจริงที่ว่าตอนนี้รหัสของคุณ ต้องเขียนโดยคำนึงถึงความปลอดภัยของเธรด

นอกจากนี้ คุณสมบัติบางอย่างของ Ruby (C APIs และหนึ่งในเครื่องมือวิปัสสนาอันทรงพลังของ Ruby คือโมดูล ObjectSpace) จะไม่ถูกนำมาใช้ใน JRuby

จากที่กล่าวมาข้อดีของการใช้ JVM อาจมีมากกว่าข้อเสียสำหรับบางสถานการณ์หรือบางโครงการ JVM ช่วยให้สามารถเพิ่มประสิทธิภาพได้หลายอย่าง เช่น การเปิดคอมไพเลอร์ JIT หรือใช้อ็อบเจ็กต์ Java และ API ดั้งเดิม

จากตัวอย่างกรณีการใช้งาน JRuby ที่น่าสนใจ อดีตเพื่อนร่วมงานของฉันเคยมีปัญหาเกี่ยวกับ CPU มาก ซึ่งเขาเริ่มแก้ไขด้วยเธรดใน Ruby 1.9.3 เมื่อเขาเปลี่ยนมาใช้ JRuby และใช้ java.util.concurrent.Executors ของ Java เขาเห็นว่ามีการปรับปรุงประสิทธิภาพของคำสั่งขนาดต่างๆ (เร็วกว่าหลายหมื่นเท่า) สำหรับการดำเนินการนี้ ดูการทดลองของเขาที่นี่

รูบิเนียส

Rubinius เป็นการนำ Ruby มาใช้ซึ่งใช้งานรันไทม์ทั่วไปสำหรับภาษาไดนามิกที่ด้านบนของเครื่องเสมือนระดับต่ำ (LLVM) การใช้โครงสร้างพื้นฐานและเทคโนโลยีคอมไพเลอร์ JIT นี้ Rubinius สามารถเรียกใช้โค้ด Ruby ได้โดยมีค่าใช้จ่ายน้อยกว่า MRI

Rubinius ยังสร้างโดยใช้ Ruby ให้ได้มากที่สุดเพื่อให้การพัฒนาล่าม / รันไทม์เร็วขึ้นและง่ายขึ้น

ข้อเท็จจริงที่น่าสนุก: ในขั้นต้น RubySpec เข้ามาอยู่ในขั้นตอนของการนำ Rubinius ไปใช้

เช่นเดียวกับ JRuby Rubinius มีคอมไพเลอร์ JIT การจัดการหน่วยความจำที่ดีขึ้น และเครื่องเสมือนที่เป็นผู้ใหญ่มากกว่า Ruby MRI อย่างไรก็ตาม ไม่เหมือนกับ JRuby ตรงที่ Rubinius รองรับไลบรารี่ Ruby C และรากฐานของ Rubinius เขียนด้วยภาษา C++ ไม่ใช่ Java

Rubinius อาจเป็นสื่อกลางที่ดีเมื่อคุณต้องการประสิทธิภาพสูงบนเซิร์ฟเวอร์ Rails ของคุณโดยไม่มีช่วงการเรียนรู้หรือข้อเสียอื่นๆ ของ JRuby

mruby

mruby ได้รับการออกแบบให้เป็น Ruby เวอร์ชันฝังตัวได้ (รองรับ Ruby 1.9.3) ด้วย mruby คุณสามารถนำเสนอ Ruby เป็นภาษาสคริปต์ / การทำงานอัตโนมัติในแอปพลิเคชันดั้งเดิม ใช้สำหรับการเขียนสคริปต์เกม และแม้แต่สำหรับการเขียนโปรแกรมบอร์ดไมโครคอนโทรลเลอร์ เช่น Raspberry Pi

หากแพลตฟอร์มของคุณมีข้อจำกัดด้านทรัพยากรที่รุนแรง mruby อาจเป็นเพียงล่าม Ruby สำหรับคุณ mruby ยังถูกใช้เพื่อ:

• สร้างแอป iOS (ในฐานะคู่แข่งของ RubyMotion ที่กล่าวถึงด้านล่าง)
• ฝัง Ruby ลงในแอป iOS เพื่อความเร็วในการพัฒนา
• เสนอภาษาสคริปต์แบบฝังตัวให้กับผู้ใช้ปลายทางเพื่อการทำงานอัตโนมัติ

เมื่อ Internet of Things กลายเป็นความจริงมากขึ้นเรื่อย ๆ ระบบอัตโนมัติในบ้านก็เข้ามาในตัวมันเอง และคอมพิวเตอร์แบบพกพามาก (และค่อนข้างทรงพลัง) เป็นเรื่องธรรมดามากขึ้น ภูมิทัศน์ของแพลตฟอร์มเป้าหมายที่ให้การสนับสนุนจึงมีความหลากหลายมากขึ้น mruby ช่วยให้สามารถทำได้ด้วยภาษาที่มีประสิทธิภาพเดียวกันกับที่ใช้บนเดสก์ท็อป

โอปอล์

Opal เป็น transpiler เพื่อเปลี่ยน Ruby เป็น JavaScript

ด้วยการเพิ่มขึ้นของ Coffeescript นักพัฒนาเรียนรู้ว่าพวกเขาไม่ต้องพิมพ์ JavaScript เพื่อ รับ JavaScript แม้ว่า Coffeescript ยอมรับว่ามีข้อดี แต่จงใช้ให้นานเพียงพอและคุณจะพบกับสิ่งที่คุณไม่ชอบเกี่ยวกับภาษานั้น

ป้อน Opal: พิมพ์ Ruby รับ Javascript สวยเย็น

Opal มุ่งมั่นที่จะมีความสอดคล้องกันมากที่สุดเท่าที่จะเป็นไปได้กับการใช้งาน Ruby อื่น ๆ ดังนั้นจึงได้รับการทดสอบกับชุดย่อยของ RubySpec แม้ว่าจะมีความไม่ลงรอยกันบางอย่างเกิดขึ้นจากธรรมชาติของ JavaScript และรันไทม์ของ JavaScript ตัวอย่างเช่น สตริงและสัญลักษณ์ใน Opal มีค่าเท่ากัน และ Opal ไม่ได้จัดเตรียมกลไกการดำเนินการเธรดหรือเชลล์ใดๆ

Opal ทำงานแบบสแตนด์อโลนหรือสามารถใช้เป็นส่วนหนึ่งของไปป์ไลน์สินทรัพย์ Rails (เช่น เพื่อแปลงไฟล์ somefile.js.rb ของคุณเป็น JavaScript โดยอัตโนมัติ)

บางทีคุณอาจมีปัญหาโดเมนที่เหมาะสมกับรูปแบบการทำงานพร้อมกันแบบอะซิงโครนัสของ JavaScript (เช่น บริการ Node.js ขนาดเล็ก) แต่ต้องการภาษาหรืออัญมณีบางส่วนจากพื้นที่ Ruby โอปอล์อาจเป็นทางออกที่ดีสำหรับคุณในกรณีนี้

หรือบางทีคุณอาจต้องการเขียนเว็บแอป Ruby แบบเต็มสแต็ก ด้วยโอปอล คุณสามารถ มีล่าม Ruby หนึ่งตัวที่รันโค้ด Ruby ฝั่งเซิร์ฟเวอร์ของคุณ จากนั้นให้ Opal สร้าง JavaScript เพื่อทำงานบนฝั่งไคลเอ็นต์

Opal ตระหนักดีว่าคุณอาจโต้ตอบกับ JavaScript API อื่นๆ (เช่น DOM หรือ Node.js) ดังนั้นจึงทำให้ง่ายต่อการเปลี่ยนเป็น JavaScript และให้น้ำตาลซินแทคติก Ruby บางส่วนเหนือไลบรารี JavaScript ทั่วไปเช่น jQuery

ลักษณะที่เน้น JavaScript ของ Opal นั้นเป็นทั้งจุดแข็งและจุดอ่อนของมัน ข้อเสีย รันไทม์ของ Opal คือรันไทม์ JavaScript และ Opal จะได้รับแจ้งจากการตัดสินใจออกแบบ JavaScript ดังนั้น หากคุณกำลังมองหาการนำ Ruby ไปใช้งานที่ดีเพื่อเขียนเชลล์สคริปต์ขนาดเล็กด้วย หรือกำลังมองหา Ruby Runtime ที่ดีกว่าสำหรับแอป Rails ของคุณ Opal อาจไม่ใช่ตัวเลือกที่ดีที่สุดของคุณ

RubyMotion

RubyMotion เป็นทั้ง (a) การใช้งาน Ruby (เขียนโดยใช้ Objective-C และ Cocoa) และ (b) ชุดของการผูกภาษาเพื่อให้นักพัฒนาสามารถเข้าถึง Cocoa API ผ่าน Ruby ได้

RubyMotion เป็นผลิตภัณฑ์เชิงพาณิชย์ที่ให้คุณเขียนแอพ Cocoa ดั้งเดิมใน Ruby RubyMotion 2.0 ให้คุณเขียนแอพ iOS และ Mac OS X ใน Ruby และ RubyMotion 3 สัญญาว่าจะนำการสนับสนุนแบบเดียวกันนี้มาสู่ Android

RubyMotion ใช้ภาษา Ruby เวอร์ชัน 1.9

การใช้งานที่หมดอายุ

หลายปีที่ผ่านมานับตั้งแต่เปิดตัว Ruby การใช้งาน Ruby บางส่วนที่มีอยู่ก็ถูกละทิ้งหรือยุติลง เช่น:

• Ruby Enterprise รุ่น (REE) REE เป็นส่วนสำคัญของ MRI 1.8 จากกลุ่มคนที่ Phusion Passenger ซึ่งใช้การปรับปรุงหน่วยความจำและการรวบรวมขยะมากมายสำหรับนักพัฒนาเว็บ เป็นเวลาหลายปีแล้วที่การนำ Ruby เริ่มต้นไปใช้จริงสำหรับไซต์ Rails ที่ใช้งานจริง ไม่เคยอัปเดตสำหรับ Ruby 1.9 หรือ Ruby 2.0 เลย และสุดท้ายก็ถูกยกเลิกในปี 2012
• ไอรอนรูบี้. IronRuby คือ Ruby ที่นำไปใช้กับ Microsoft .NET ซึ่งเขียนด้วยภาษา C# และในขณะที่โครงการนี้ได้รับทุนจาก Microsoft ถูกละทิ้งในปี 2011 IronRuby รองรับ Ruby 1.8.6 ล่าสุด

สรุป

มีรันไทม์และล่ามที่หลากหลายให้เลือกจากแนว Ruby สำหรับโปรเจ็กต์ Ruby ส่วนใหญ่ การใช้งานอ้างอิง Ruby (Ruby MRI) ยังคงเป็นล่ามที่เลือกไว้ อย่างไรก็ตาม การใช้งาน Ruby แบบอื่นอาจเป็นทางเลือกที่เหมาะสมสำหรับโครงการของคุณ ขึ้นอยู่กับเป้าหมายและข้อจำกัดด้านการทำงานและทางเทคนิคของคุณ

ในบทบาทการนำ Ruby ไปใช้อ้างอิง MRI จะได้รับฟีเจอร์ภาษาใหม่เร็วขึ้น มีการทำงานพร้อมกันและเรื่องราวหน่วยความจำที่ดีเพียงพอ (ที่มีแต่จะดีขึ้นเท่านั้น) และมีความเข้ากันได้กว้างที่สุดกับ gem (บางส่วนเขียนด้วยภาษา C บางส่วน) โดยรวมแล้ว MRI เป็นตัวเลือกที่มั่นคงและเชื่อถือได้สำหรับรหัส Ruby วัตถุประสงค์ทั่วไป

สำหรับการปรับใช้ระดับองค์กรที่ใหญ่ขึ้น หรือสำหรับสถานการณ์ที่คุณต้องการโต้ตอบกับโค้ด Java (หรือภาษา JVM อื่นๆ) หรือต้องการรูปแบบการทำงานพร้อมกันที่พัฒนาขึ้นอย่างมาก JRuby เป็นตัวเลือกที่น่าสนใจ

และแน่นอน ถ้าคุณมีความต้องการเฉพาะตัว (เช่น การเขียน JavaScript ทำงานบนอุปกรณ์ฝังตัวรุ่นปัจจุบัน และอื่นๆ) ทางเลือกอื่นของ Ruby อาจเป็นสิ่งที่คุณกำลังมองหา

ด้วยรันไทม์และล่ามของ Ruby ที่หลากหลายให้เลือก Ruby แสดงให้เห็นว่าเป็นภาษาที่ยืดหยุ่น มีประโยชน์สำหรับสภาพแวดล้อมการประมวลผลที่หลากหลาย ตั้งแต่ร้านการปรับใช้ Java ขนาดใหญ่ขององค์กร ไปจนถึงซอฟต์แวร์ที่ควบคุมไฟหยุดในสำนักงานของคุณ คุณติด Raspberry Pi ของคุณในสุดสัปดาห์ที่ผ่านมา การเลือกเครื่องมือที่เหมาะสมเพื่อจุดประสงค์ที่ถูกต้องเป็นสิ่งสำคัญ ใช่ แต่หวังว่าบทความนี้จะแสดงให้คุณเห็นว่า Ruby เป็นมากกว่าล่าม Ruby เริ่มต้นที่มาพร้อมกับระบบปฏิบัติการของคุณ

โลกของ Ruby ได้รับการปรับปรุงอย่างมากโดยทีมติดตั้ง Ruby ทางเลือกที่ทำงานร่วมกับทีม Ruby MRI หลักเมื่อมีการเสนอให้เปลี่ยนภาษา พวกเขาเพิ่มความหลากหลายให้กับชุมชนการปรับใช้ Ruby เพิ่มประสบการณ์การใช้งาน Ruby ที่ได้รับมาอย่างหนัก และมุมมองของตนเองเกี่ยวกับคุณสมบัติที่จะเข้าสู่ภาษา ผู้ที่ชื่นชอบทับทิมเป็นหนี้บุญคุณทีมเหล่านี้อย่างมาก ขอชื่นชมในความพยายามของพวกเขา!