Ruby 프로그래밍 언어의 많은 인터프리터 및 런타임

소개

ruby gem의 음영이 많은 것처럼 Ruby 인터프리터도 여러 가지 구현되어 있습니다.

가장 일반적으로 사용되는 Ruby 인터프리터는 Ruby 창시자(Yukihiro Matsumoto)와 Ruby 핵심 팀이 C로 개발한 참조 구현인 Ruby MRI입니다.

Ruby on Rails 고용 가이드에서는 Rails의 일부 단점이 대체 Ruby 인터프리터를 사용하여 잠재적으로 해결하거나 피할 수 있다고 언급합니다. 이 기사에서는 현재 사용 가능한 다양한 기존 Ruby 인터프리터 구현 및 런타임을 보여주고 각각의 장점과 단점을 논의합니다.

Ruby 버전 기록(및 대체 구현에 미치는 영향)

안타깝게도 Ruby용 Python 언어 참조에 해당하는 항목이 없습니다(ISO/IEC 30170:2012에는 Ruby 1.8/Ruby 1.9가 설명되어 있지만 Ruby 2.x에는 해당 사양이 없습니다). 이러한 언어 사양이 없는 경우 Ruby 구현자는 일반적으로 Ruby 인터프리터에서 실행할 수 있는 테스트를 통해 Ruby 언어의 예상 동작을 지정하는 커뮤니티 기반 RubySpec에 의존합니다. 따라서 RubySpec은 Ruby 구현자가 사실상 표준에 대한 Ruby 구현의 동작 준수를 확인하는 데 사용됩니다.

공식적인 사양이 없기 때문에 Ruby의 새 릴리스는 종종 단순히 Ruby MRI의 새 릴리스에 해당합니다. Ruby MRI에서 Ruby(언어)를 분리하기 위한 설계 프로세스를 논의하는 공개 문제가 있다는 점은 주목할 가치가 있습니다.

그러나 현재 Ruby 언어와 MRI 참조 구현 간의 긴밀한 결합을 감안할 때 대체 Ruby 구현의 개발자는 각 새로운 MRI 릴리스에 도입된 언어 변경 사항을 따라잡기 위해 고군분투합니다.

Ruby 1.8과 Ruby 1.9 사이의 전환보다 더 어려운 일은 없었습니다. 2007년에 Ruby의 구문을 정리하고 통합하기 위한 노력의 일환으로(Ruby 1.0 릴리스 이후 10년 동안 언어가 발전함에 따라) Ruby 코어 팀은 Ruby 1.9.0을 출시했습니다. 이 버전은 언어에 많은 이전 버전 비호환성을 도입했습니다. . 결과적으로 모든 Ruby 구현이 1.8에서 1.9로 구문을 향상시키는 데 필요한 노력을 투자한 것은 아닙니다. 따라서 커뮤니티에서 더 이상 사용하지 않는 여러 1.8 기반 Ruby 구현이 있지만 여전히 온라인에서 찾거나 오래된 Ruby 손에 의해 이야기될 수 있습니다.

Ruby MRI의 새 버전은 의미론적 버전 관리 원칙에 따라 크리스마스마다 릴리스됩니다. Ruby 2.0(2013년 출시) 및 2.1(2014년 출시)은 각각 Ruby 1.9와의 역호환성을 유지하면서 Ruby 개발자가 활용할 수 있는 추가 언어 기능을 도입했습니다.

대체 Ruby 구현을 사용하는 이유는 무엇입니까? MRI에 무슨 문제가 있습니까?

다양한 사용 사례와 환경을 지원하는 다양한 대체 Ruby 구현이 있습니다. 자바 엔터프라이즈 환경. 모바일 애플리케이션. 자바스크립트 구현. 낮은 CPU/RAM 기계. 이러한 사용 사례를 지원하는 것 외에도 대체 구현은 응용 프로그램의 특성에 따라 속도를 추가로 높이거나 메모리를 보다 효율적으로 사용할 수도 있습니다.

오랫동안 많은 Ruby on Rails 개발자는 MRI 대신 REE(Ruby Enterprise Edition)를 사용하여 당시 MRI 버전에 비해 REE의 더 나은 메모리 관리 기술을 활용했습니다. (REE는 이후 2012년에 중단되었습니다.)

MRI는 기본 Ruby 구현이지만 모든 환경 및 시나리오에 대해 반드시 올바른 선택은 아닙니다. 예를 들어, MRI의 동시성 지원은 JRuby 또는 Rubinius의 동시성 지원보다 열등합니다. 또한 MRI의 메모리 및 가비지 수집 방식이 지속적으로 개선되고 있지만 여전히 몇 가지 문제가 있습니다.

다음에 나오는 Ruby 구현에 대한 설문조사는 프로젝트의 운영 목표와 제약 조건에 가장 적합한 인터프리터를 선택하는 데 도움을 주기 위한 것입니다.

Matz's Ruby Interpreter (MRI) / CRuby

Yukihiro Matsumoto(“Matz”, Ruby 제작자)가 이끄는 Ruby 핵심 팀이 C로 작성한 MRI는 사실상 표준 역할을 하는 Ruby의 참조 구현입니다. 예를 들어 OS 공급업체가 OS 설치 소프트웨어의 일부로 Ruby 버전을 포함하는 경우 일반적으로 MRI 버전입니다. MRI는 다른 Ruby 구현보다 더 많은 급여를 받는 핵심 팀 구성원과 Ruby 생태계를 개선하려는 사람이나 회사의 헌신적인 리소스로부터 혜택을 받습니다.

표준 라이브러리 변경 사항 외에 새로운 언어 기능을 구현하는 경우가 많은 Ruby MRI의 새 버전은 매년 크리스마스에 출시됩니다. 기능은 일반적으로 Ruby 핵심 개발자 메일링 목록에 대한 토론을 기반으로 Ruby MRI에서 먼저 구현됩니다. 다른 Ruby 구현은 어떤 경우에는 몇 년까지도 뒤쳐집니다.

JRuby

JRuby는 JVM(Java Virtual Machine) 위에 구현된 Ruby 버전입니다. Java 이외의 언어에서 JVM(Clojure 및 Scala)에서 실행되는 것이 대중화됨에 따라 JVM 기반 Ruby 구현이 인기를 얻게 될 것입니다.

JVM의 Ruby는 또한 Ruby가 Java를 실행할 수 있는 모든 곳에서 실행할 수 있음을 의미합니다(예: Ruboto를 사용하는 Android 휴대폰). 또한 JVM의 상호 운용성 덕분에 JRuby 코드는 표준 및 타사 라이브러리를 포함하여 Java 플랫폼을 사용할 수 있습니다.

JRuby는 또한 Rails 기반 솔루션을 Java 전용 배포 환경으로 가져오고, Rails 앱을 .war 파일로 패키징하여 Tomcat 컨테이너에 배포하거나 웹 프런트 엔드의 일부로 실행되는 Java 애플릿으로 패키징하는 데 유용합니다. , 예를 들어.

그러나 JVM에 익숙하지 않은 사람들을 위해 JRuby는 Ruby 인터프리터의 느린 시작, 타사 Java 라이브러리를 사용하는 경우 CLASSPATH 문제 디버깅, 더 큰 메모리 사용량 및 이제 코드가 스레드 안전성을 염두에 두고 작성해야 합니다.

또한 Ruby의 일부 기능(C API 및 Ruby의 강력한 내부 검사 도구 중 하나인 ObjectSpace 모듈)은 JRuby에서 구현되지 않습니다.

그렇긴 하지만 JVM 사용의 장점은 특정 상황이나 프로젝트의 단점보다 클 수 있습니다. JVM은 JIT 컴파일러 켜기 또는 기본 Java 개체 및 API 사용과 같은 많은 성능 최적화를 허용합니다.

강력한 JRuby 사용 사례의 예로, 제 이전 동료는 한때 Ruby 1.9.3의 스레드로 처음 해결한 CPU 집약적 문제가 있었습니다. JRuby로 전환하고 Java의 java.util.concurrent.Executors 를 사용했을 때 그는 이 작업에서 성능이 수십 배(수만 배 더 빠름) 향상되는 것을 보았습니다. 여기에서 그의 실험을 참조하십시오.

루비니우스

Rubinius는 LLVM(Low Level Virtual Machine) 위에 동적 언어에 대한 일반 런타임을 구현하는 Ruby의 구현입니다. 이 인프라와 JIT 컴파일러 기술을 사용하여 Rubinius는 종종 MRI보다 적은 오버헤드로 Ruby 코드를 실행할 수 있습니다.

또한 Rubinius는 인터프리터/런타임의 개발을 더 빠르고 쉽게 하기 위해 가능한 한 많은 Ruby를 사용하여 빌드됩니다.

재미있는 사실: RubySpec은 처음에 Rubinius를 구현하는 과정에 있었습니다.

JRuby와 마찬가지로 Rubinius에는 JIT 컴파일러, 더 나은 메모리 관리, Ruby MRI보다 더 성숙한 가상 머신이 포함되어 있습니다. 그러나 JRuby와 달리 Rubinius는 Ruby C 라이브러리를 지원하며 Rubinius의 기반은 Java가 아닌 C++로 작성되었습니다.

Rubinius는 학습 곡선이나 JRuby의 다른 단점 없이 Rails 서버에서 고성능이 필요할 때 좋은 중간 지점이 될 수 있습니다.

뮤비

mruby는 Ruby의 임베드 가능한 버전으로 설계되었습니다(Ruby 1.9.3 지원). mruby를 사용하면 Ruby를 기본 애플리케이션에서 스크립팅/자동화 언어로 제공하고 게임 스크립팅, 심지어 Raspberry Pi와 같은 마이크로컨트롤러 보드 프로그래밍에도 사용할 수 있습니다.

플랫폼에 심각한 리소스 제약이 있는 경우 mruby는 Ruby 인터프리터일 수 있습니다. mruby는 다음 용도로도 사용됩니다.

• iOS 앱 빌드(아래에서 설명하는 RubyMotion의 경쟁자)
• 개발 속도를 위해 iOS 앱에 Ruby 포함
• 자동화 목적으로 최종 사용자에게 임베디드 스크립팅 언어 제공

사물 인터넷이 점점 더 현실화되고, 홈 자동화가 자체적으로 등장하고, 휴대가 간편한(그리고 상대적으로 강력한) 컴퓨터가 보편화되면서 지원해야 할 대상 플랫폼의 환경이 점점 더 다양해지고 있습니다. mruby는 데스크탑에서 사용하는 것과 동일한 생산적인 언어로 그렇게 할 수 있도록 도와줍니다.

오팔

Opal은 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 공간에서 언어나 특정 보석을 원할 수 있습니다. 이 경우 Opal이 좋은 솔루션이 될 수 있습니다.

또는 전체 스택 Ruby 웹 앱을 작성하고 싶을 수도 있습니다. 오팔과 함께라면 가능합니다. 하나의 Ruby 인터프리터가 서버 측 Ruby 코드를 실행하도록 한 다음 Opal이 클라이언트 측에서 실행할 JavaScript를 생성하도록 합니다.

Opal은 다른 JavaScript API(예: DOM 또는 Node.js)와 상호 작용할 가능성이 있음을 인식합니다. 따라서 JavaScript로 쉽게 전환할 수 있으며 jQuery와 같은 일반적인 JavaScript 라이브러리에 대한 일부 Ruby 구문 설탕을 제공합니다.

하지만 Opal의 JavaScript 중심적인 특성은 장점이자 단점입니다. 단점으로 Opal의 런타임은 JavaScript 런타임이고 Opal은 JavaScript 설계 결정에 따라 정보를 받습니다. 따라서 작은 셸 스크립트를 작성하기 위한 Ruby의 우수한 구현을 찾거나 Rails 앱을 위한 더 나은 Ruby 런타임을 찾고 있다면 Opal이 최선의 선택이 아닐 것입니다.

루비모션

RubyMotion은 (a) Ruby 구현(Objective-C 및 Cocoa를 사용하여 작성)이고 (b) 개발자가 Ruby를 통해 Cocoa API에 액세스할 수 있도록 하는 언어 바인딩 세트입니다.

RubyMotion은 Ruby에서 Cocoa 네이티브 앱을 작성할 수 있게 해주는 상용 제품입니다. RubyMotion 2.0을 사용하면 iOS 및 Mac OS X 앱을 Ruby로 작성할 수 있으며 RubyMotion 3은 Android에서도 이와 동일한 지원을 약속합니다.

RubyMotion은 Ruby 언어 버전 1.9를 구현합니다.

사라진 구현

Ruby가 처음 소개된 이후 몇 년 동안 다음과 같이 일부 Ruby 구현이 중단되거나 중단되었습니다.

• 루비 엔터프라이즈 에디션(REE). REE는 웹 개발자를 위해 많은 메모리 및 가비지 수집 개선 사항을 구현한 Phusion Passenger의 MRI 1.8 포크였습니다. 몇 년 동안 프로덕션 Rails 사이트에 배포된 기본 Ruby 구현이었습니다. 그러나 Ruby 1.9 또는 Ruby 2.0용으로 업데이트되지 않았으며 궁극적으로 2012년에 중단되었습니다.
• 아이언루비. IronRuby는 Microsoft .NET 위에 구현된 Ruby이며 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가 OS와 함께 제공되는 기본 Ruby 인터프리터 그 이상이라는 것을 보여주길 바랍니다.

Ruby의 세계는 언어 변경이 제안됨에 따라 핵심 Ruby MRI 팀과 협력하는 대체 Ruby 구현 팀에 의해 크게 향상되었습니다. 그들은 Ruby 구현 커뮤니티에 다양성을 추가하고, 어렵게 얻은 Ruby 구현 경험과 언어에 적용되는 기능에 대한 고유한 관점을 추가합니다. 루비 애호가들은 이 팀들에게 큰 감사의 빚을 지고 있습니다. 그들의 노력에 경의를 표합니다!