Banyaknya Interpreter dan Runtime dari Bahasa Pemrograman Ruby

pengantar

Sama seperti ada banyak nuansa permata ruby, ada beberapa implementasi dari interpreter Ruby.

Interpreter Ruby yang paling umum digunakan adalah implementasi referensi, Ruby MRI, yang dikembangkan di C oleh pencipta Ruby (Yukihiro Matsumoto) dan tim inti Ruby.

Panduan Perekrutan Ruby on Rails kami menyebutkan bahwa beberapa kelemahan di Rails berpotensi dapat diselesaikan atau dihindari dengan menggunakan penerjemah Ruby alternatif. Artikel ini menampilkan berbagai implementasi dan runtime interpreter Ruby yang tersedia saat ini, membahas kelebihan dan kekurangan masing-masing.

Riwayat Versi Ruby (dan bagaimana pengaruhnya terhadap implementasi alternatif)

Sayangnya, tidak ada yang setara dengan Referensi Bahasa Python untuk Ruby (ISO/IEC 30170:2012 menjelaskan Ruby 1.8 / Ruby 1.9, tetapi tidak ada spesifikasi yang sesuai untuk Ruby 2.x). Dengan tidak adanya spesifikasi bahasa seperti itu, pelaksana Ruby biasanya mengandalkan RubySpec berbasis komunitas yang menetapkan perilaku yang diharapkan dari bahasa Ruby melalui pengujian yang dapat dijalankan di penerjemah Ruby mana pun. Oleh karena itu RubySpec digunakan oleh pelaksana Ruby untuk memverifikasi kepatuhan perilaku implementasi Ruby mereka dengan standar de facto.

Karena kurangnya spesifikasi formal, rilis baru Ruby seringkali hanya sesuai dengan rilis baru dari Ruby MRI. Perlu dicatat bahwa ada masalah terbuka yang membahas proses desain untuk memisahkan Ruby (bahasa) dari Ruby MRI.

Namun, mengingat hubungan yang ketat saat ini, antara bahasa Ruby dan implementasi referensi MRI, pengembang implementasi Ruby alternatif terkadang kesulitan untuk mengikuti perubahan bahasa yang diperkenalkan di setiap rilis MRI baru.

Tidak pernah sesulit ini dalam transisi antara Ruby 1.8 dan Ruby 1.9. Pada tahun 2007, dalam upaya untuk membersihkan dan mengkonsolidasikan sintaks Ruby (sebagai bahasa telah berkembang dalam dekade sejak rilis Ruby 1.0), tim inti Ruby merilis Ruby 1.9.0, sebuah versi yang memperkenalkan banyak inkompatibilitas mundur ke dalam bahasa. . Akibatnya, tidak semua implementasi Ruby menginvestasikan upaya yang diperlukan untuk membuat lompatan sintaksis dari 1,8 ke 1,9. Dengan demikian, ada beberapa implementasi Ruby berbasis 1.8 yang tidak digunakan lagi oleh komunitas, tetapi mungkin masih Anda temukan secara online atau dibicarakan oleh tangan Ruby lama.

Versi baru Ruby MRI dirilis setiap Natal, mengikuti prinsip versi semantik. Ruby 2.0 (dirilis 2013) dan 2.1 (dirilis 2014) masing-masing memperkenalkan fitur bahasa tambahan yang dapat dimanfaatkan oleh pengembang Ruby, tanpa mengorbankan kompatibilitas mundur dengan Ruby 1.9.

Mengapa menggunakan implementasi Ruby alternatif? Apa yang salah dengan MRI?

Ada berbagai implementasi Ruby alternatif, yang mendukung beragam kasus penggunaan dan lingkungan. lingkungan Perusahaan Jawa. Aplikasi seluler. implementasi JavaScript. Mesin CPU/RAM rendah. Selain mendukung kasus penggunaan ini, implementasi alternatif terkadang juga menawarkan peningkatan kecepatan ekstra atau penggunaan memori yang lebih efisien, bergantung pada karakteristik aplikasi Anda.

Untuk waktu yang lama banyak pengembang Ruby on Rails menggunakan Ruby Enterprise Edition (REE) alih-alih MRI, memanfaatkan teknik manajemen memori yang lebih baik di REE dibandingkan dengan versi MRI pada waktu itu. (REE kemudian dihentikan meskipun pada tahun 2012.)

Meskipun MRI adalah implementasi Ruby default, itu belum tentu merupakan pilihan yang tepat untuk semua lingkungan dan skenario. Misalnya, dukungan konkurensi MRI lebih rendah daripada JRuby atau Rubinius. Juga, meskipun memori MRI dan skema pengumpulan sampah terus meningkat, mereka masih memiliki beberapa masalah.

Survei implementasi Ruby berikut ini dimaksudkan untuk membantu Anda dalam memilih penerjemah yang paling sesuai dengan tujuan dan batasan operasional proyek Anda.

Matz's Ruby Interpreter (MRI) / CRuby

Ditulis dalam bahasa C oleh tim inti Ruby yang dipimpin oleh Yukihiro Matsumoto (“Matz”, pencipta Ruby), MRI adalah implementasi referensi Ruby yang berfungsi sebagai standar de facto. Jika vendor OS menyertakan versi Ruby sebagai bagian dari perangkat lunak yang diinstal OS, misalnya, biasanya versi MRI. MRI mendapat manfaat dari lebih banyak anggota tim inti yang dibayar daripada implementasi Ruby lainnya, serta sumber daya yang disumbangkan yang didedikasikan dari orang atau perusahaan yang ingin meningkatkan ekosistem Ruby.

Versi baru Ruby MRI – sering kali mengimplementasikan fitur bahasa baru, selain perubahan pustaka standar – dirilis setiap Natal. Fitur diimplementasikan di Ruby MRI terlebih dahulu, biasanya berdasarkan diskusi di milis pengembang inti Ruby. Implementasi Ruby lainnya tertinggal, dalam beberapa kasus bahkan bertahun-tahun.

JRuby

JRuby adalah versi Ruby yang diimplementasikan di atas Java Virtual Machine (JVM). Karena menjadi populer untuk bahasa di luar Java untuk berjalan di atas JVM (Saya melihat ke arah Anda, Clojure dan Scala), implementasi Ruby berbasis JVM kemungkinan akan semakin populer.

Ruby di JVM juga berarti bahwa Ruby dapat berjalan di mana saja Java dapat berjalan (seperti ponsel Android, menggunakan Ruboto misalnya). Selain itu, berkat interoperabilitas JVM, kode JRuby dapat menggunakan platform Java, termasuk pustaka standar dan pihak ke-3.

JRuby juga berguna untuk membawa solusi berbasis Rails ke lingkungan penerapan Java saja, mengemas aplikasi Rails sebagai file .war untuk disebarkan ke wadah Tomcat, atau sebagai applet Java yang berjalan sebagai bagian dari front-end web Anda , Misalnya.

Namun, bagi mereka yang tidak terbiasa dengan JVM, JRuby menghadirkan masalah terkait JVM standar seperti startup interpreter Ruby yang lambat, men-debug masalah CLASSPATH jika Anda menggunakan perpustakaan Java pihak ketiga, penggunaan memori yang lebih besar, dan fakta bahwa sekarang kode Anda perlu ditulis dengan mempertimbangkan keamanan benang.

Juga, beberapa fitur Ruby (API C, dan salah satu alat introspeksi Ruby yang kuat, modul ObjectSpace) tidak diimplementasikan di JRuby.

Semua yang dikatakan, keuntungan menggunakan JVM mungkin lebih besar daripada kerugian untuk situasi atau proyek tertentu. JVM memungkinkan banyak pengoptimalan kinerja, seperti menyalakan kompiler JIT, atau menggunakan objek dan API Java asli.

Sebagai contoh kasus penggunaan JRuby yang menarik, mantan rekan kerja saya pernah memiliki masalah intensif CPU yang awalnya ia selesaikan dengan utas di Ruby 1.9.3. Ketika dia beralih ke JRuby dan menggunakan java.util.concurrent.Executors , dia melihat peningkatan kinerja beberapa kali lipat (puluhan ribu kali lebih cepat) untuk operasi ini. Lihat eksperimennya di sini.

Rubinius

Rubinius adalah implementasi Ruby yang mengimplementasikan runtime generik untuk bahasa dinamis di atas Mesin Virtual Tingkat Rendah (LLVM). Dengan menggunakan infrastruktur dan teknologi compiler JIT ini, Rubinius sering kali dapat menjalankan kode Ruby dengan overhead yang lebih sedikit daripada MRI.

Rubinius juga dibangun menggunakan Ruby sebanyak mungkin untuk membuat pengembangan interpreter/runtime lebih cepat dan mudah.

Fakta menyenangkan: RubySpec awalnya muncul dalam proses implementasi Rubinius.

Seperti JRuby, Rubinius menyertakan kompiler JIT, manajemen memori yang lebih baik, dan mesin virtual yang lebih matang daripada Ruby MRI. Namun, tidak seperti JRuby, Rubinius mendukung perpustakaan Ruby C dan dasar-dasar Rubinius ditulis dalam C++, bukan Java.

Rubinius mungkin merupakan jalan tengah yang baik ketika Anda membutuhkan kinerja tinggi di server Rails Anda tanpa kurva belajar atau kelemahan JRuby lainnya.

mruby

mruby dirancang untuk menjadi versi Ruby yang dapat disematkan (mendukung Ruby 1.9.3). Dengan mruby, Anda dapat menawarkan Ruby sebagai bahasa skrip / otomatisasi dalam aplikasi asli, menggunakannya untuk skrip game, dan bahkan untuk memprogram papan mikrokontroler seperti Raspberry Pi.

Jika platform Anda memiliki kendala sumber daya yang parah, mruby mungkin hanya penerjemah Ruby untuk Anda. mruby juga digunakan untuk:

• Bangun aplikasi iOS (sebagai pesaing RubyMotion, dibahas di bawah)
• Sematkan Ruby ke dalam aplikasi iOS, untuk kecepatan pengembangan
• Tawarkan kepada pengguna akhir bahasa skrip yang disematkan untuk tujuan otomatisasi

Dengan Internet of Things menjadi semakin menjadi kenyataan, otomatisasi rumah menjadi miliknya sendiri, dan komputer yang sangat portabel (dan relatif kuat) menjadi lebih umum, lanskap platform target untuk didukung menjadi semakin beragam. mruby membantu memungkinkan untuk melakukannya dengan bahasa produktif yang sama yang akan digunakan di desktop.

Opal

Opal adalah transpiler untuk mengubah Ruby menjadi JavaScript.

Dengan munculnya Coffeescript, pengembang belajar bahwa mereka tidak perlu mengetik JavaScript untuk mendapatkan JavaScript. Meskipun Coffeescript memang memiliki kelebihan, gunakan cukup lama dan Anda pasti akan mengalami hal-hal yang tidak Anda sukai tentang bahasa tersebut.

Masukkan Opal: Ketik Ruby, dapatkan Javascript . Cukup keren.

Opal berusaha untuk sekonsisten mungkin dengan implementasi Ruby lainnya dan oleh karena itu juga diuji terhadap subset RubySpec. Beberapa ketidakcocokan memang ada, yang berasal dari sifat JavaScript dan runtime JavaScript. Misalnya, string dan simbol di Opal adalah sama, dan Opal tidak menyediakan mekanisme eksekusi threading atau shell.

Opal berjalan mandiri atau dapat digunakan sebagai bagian dari jalur aset Rails (misalnya, untuk secara otomatis mentranspile file somefile.js.rb Anda ke dalam JavaScript).

Mungkin Anda memiliki domain masalah yang cocok untuk pola konkurensi asinkron JavaScript (seperti layanan Node.js kecil) tetapi menginginkan bahasa atau permata tertentu dari ruang Ruby. Opal mungkin merupakan solusi yang baik untuk Anda dalam hal ini.

Atau mungkin Anda ingin menulis aplikasi web Ruby tumpukan penuh. Dengan Opal, Anda bisa. Mintalah satu juru bahasa Ruby untuk menjalankan kode Ruby sisi server Anda dan kemudian minta Opal menghasilkan JavaScript untuk dijalankan di sisi klien.

Opal mengenali bahwa Anda kemungkinan besar akan berinteraksi dengan API JavaScript lain (DOM, atau Node.js misalnya). Oleh karena itu memudahkan transisi ke JavaScript dan menyediakan gula sintaksis Ruby di atas pustaka JavaScript umum seperti jQuery.

Sifat JavaScript-sentris Opal, bagaimanapun, adalah kekuatan dan kelemahannya. Pada sisi negatifnya, runtime Opal adalah runtime JavaScript, dan Opal diinformasikan oleh keputusan desain JavaScript. Jadi, jika Anda mencari implementasi Ruby yang baik untuk menulis skrip shell kecil, atau mencari runtime Ruby yang lebih baik untuk aplikasi Rails Anda, Opal mungkin bukan pilihan terbaik Anda.

RubyMotion

RubyMotion adalah (a) implementasi Ruby (ditulis menggunakan Objective-C dan Cocoa) dan (b) satu set binding bahasa sehingga pengembang dapat mengakses Cocoa API melalui Ruby.

RubyMotion adalah produk komersial yang memungkinkan Anda untuk menulis aplikasi asli Kakao di Ruby. RubyMotion 2.0 memungkinkan Anda untuk menulis aplikasi iOS dan Mac OS X di Ruby, dan RubyMotion 3 berjanji untuk memberikan dukungan yang sama ini ke Android.

RubyMotion mengimplementasikan versi 1.9 dari bahasa Ruby.

Implementasi Mati

Selama bertahun-tahun sejak Ruby pertama kali diperkenalkan, beberapa implementasi Ruby yang muncul telah ditinggalkan atau dihentikan, seperti:

• Ruby Enterprise Edition (REE). REE adalah cabang dari MRI 1.8 dari orang-orang di Phusion Passenger yang menerapkan banyak peningkatan memori dan pengumpulan sampah untuk pengembang web. Selama beberapa tahun, itu adalah implementasi Ruby default yang digunakan untuk situs Rails produksi. Itu tidak pernah diperbarui untuk Ruby 1.9 atau Ruby 2.0, dan akhirnya dihentikan pada tahun 2012.
• BesiRuby. IronRuby adalah Ruby yang diimplementasikan di atas Microsoft .NET, ditulis dalam C#, dan untuk sementara proyek ini didanai oleh Microsoft. Ditinggalkan pada tahun 2011, IronRuby terakhir mendukung Ruby 1.8.6.

Bungkus

Ada berbagai macam runtime dan interpreter untuk dipilih di lanskap Ruby. Untuk sebagian besar proyek Ruby, implementasi referensi Ruby (Ruby MRI) tetap menjadi penerjemah pilihan. Namun, implementasi Ruby alternatif mungkin merupakan pilihan yang tepat untuk proyek Anda, tergantung pada tujuan dan kendala fungsional dan teknis Anda.

Dalam perannya sebagai implementasi referensi Ruby, MRI mendapatkan fitur bahasa baru lebih cepat, memiliki cerita konkurensi dan memori yang cukup baik (yang semakin baik), dan memiliki kompatibilitas terluas dengan permata (beberapa ditulis sebagian dalam C). Secara keseluruhan, MRI adalah pilihan yang solid dan dapat diandalkan untuk kode Ruby tujuan umum.

Untuk penerapan perusahaan yang lebih besar, atau untuk situasi di mana Anda perlu berinteraksi dengan kode Java (atau bahasa JVM lainnya) atau membutuhkan pola konkurensi yang sangat berkembang, JRuby adalah opsi yang menarik.

Dan tentu saja, jika Anda memiliki kebutuhan yang unik (misalnya, menulis JavaScript, menjalankan generasi sekarang dari perangkat yang disematkan, dan sebagainya), alternatif Ruby lainnya mungkin yang Anda cari.

Dengan berbagai macam runtime Ruby dan interpreter untuk dipilih, Ruby menunjukkan dirinya sebagai bahasa yang fleksibel, berguna untuk beragam lingkungan komputasi, mulai dari toko penerapan Java besi besar perusahaan, hingga perangkat lunak yang mengontrol lampu lalu lintas di kantor Anda Anda mengaitkan Raspberry Pi Anda ke akhir pekan lalu. Memilih alat yang tepat untuk tujuan yang tepat sangat penting, ya, tetapi semoga artikel ini menunjukkan kepada Anda bahwa Ruby jauh lebih dari sekadar penerjemah Ruby default yang disertakan dengan OS Anda.

Dunia Ruby sangat ditingkatkan oleh tim implementasi Ruby alternatif yang bekerja dengan tim inti Ruby MRI saat perubahan bahasa diusulkan. Mereka menambahkan keragaman pada komunitas implementasi Ruby, menambahkan pengalaman implementasi Ruby yang diperoleh dengan susah payah dan perspektif mereka sendiri tentang fitur-fitur yang masuk ke dalam bahasa tersebut. Penggemar Ruby secara kolektif berutang banyak terima kasih kepada tim-tim ini. Kudos kepada mereka atas usaha mereka!