루비 4.0.0
(ruby-lang.org)- 루비 4.0.0이 공개되어, 새로운 Ruby Box와 ZJIT를 도입하고 다수의 성능 및 언어 개선을 포함
- Ruby Box는 클래스, 모듈, 전역 변수, 네이티브/루비 라이브러리 정의를 격리 실행할 수 있는 실험적 기능
- ZJIT는 Rust 기반 차세대 JIT 컴파일러로, 기존 YJIT보다 구조적으로 확장 가능하며 외부 기여를 용이하게 함
- Ractor 병렬 실행 모델이 안정성과 성능 면에서 개선되어, 향후 실험적 상태를 해제할 예정
- 핵심 클래스, 표준 라이브러리, C API, GC, JIT 등 전반에 걸친 업데이트로 루비 생태계의 성능과 확장성을 강화
Ruby 4.0 개요
- Ruby 4.0.0은 Ruby Box와 ZJIT를 중심으로 한 대규모 업데이트 버전
- 병렬 실행, 언어 문법, 표준 라이브러리, GC, JIT 등 다양한 영역에서 개선 포함
- 다운로드는
.tar.gz,.tar.xz,.zip형식으로 제공
Ruby Box
-
Ruby Box는 정의의 격리를 제공하는 실험적 기능
- 환경 변수
RUBY_BOX=1설정 시 활성화되며, 클래스는Ruby::Box - 박스 내부에서 로드된 정의는 외부와 격리되어, monkey patch, 전역/클래스 변수, 클래스/모듈 정의, 라이브러리 변경이 다른 박스에 영향을 주지 않음
- 환경 변수
- 주요 사용 예시
- 테스트 케이스 간 격리 실행
- 블루-그린 배포를 위한 병렬 웹앱 실행
- 의존성 업데이트 검증용 병렬 실행
- 향후 고수준 “패키지 API” 구현의 기반 API로 활용 예정
ZJIT
-
ZJIT는 YJIT의 차세대 버전으로 개발된 새 JIT 컴파일러
- Rust 1.85.0 이상 필요,
--zjit옵션으로 활성화 - SSA IR 기반의 더 큰 컴파일 단위를 지원하며, 외부 기여를 촉진하는 구조
- Rust 1.85.0 이상 필요,
- 현재 인터프리터보다 빠르지만 YJIT보다 느림
- 프로덕션 사용은 권장되지 않으며, Ruby 4.1에서 성능 향상 예정
Ractor 개선
- Ractor::Port 클래스 추가로 메시지 송수신 문제 해결
-
Ractor.shareable_proc으로 Ractor 간 Proc 객체 공유 용이 - 내부 데이터 구조 개선으로 글로벌 락 경합 감소, 병렬성 향상
- Ractor의 실험적 상태를 다음 해에 해제 예정
언어 변경
-
*nil이 더 이상nil.to_a를 호출하지 않음 (**nil과 동일한 동작) - 논리 연산자(
||,&&,and,or)가 라인 연속(dot chaining) 문법을 지원 - 코드 가독성과 일관성 향상
핵심 클래스 업데이트
-
Array:
Array#rfind,Array#find추가로 효율적 탐색 지원 -
Binding: 번호 매개변수 제외 및
implicit_parameters관련 메서드 추가 -
Enumerator:
produce에size:키워드 인자 추가 -
ErrorHighlight:
ArgumentError발생 시 호출자·정의부 코드 스니펫 표시 -
Fiber/Fiber::Scheduler:
raise(cause:),fiber_interrupt,yield등 추가 -
File: Linux에서
File::Stat#birthtime지원 -
IO:
Float::INFINITY타임아웃 허용, 파이프 기반 프로세스 생성 제거 -
Kernel:
#inspect커스터마이징 가능,Kernel#open의 파이프 생성 제거 -
Math:
log1p,expm1추가 - Pathname: 기본 젬에서 코어 클래스로 승격
- Proc: 익명 매개변수 출력 형식 통일
-
Ractor:
Ractor::Port기반 통신 구조로 변경,Ractor.yield등 제거 -
Set: 코어 클래스로 승격,
inspect형식 단순화 -
Socket:
open_timeout인자 추가, 타임아웃 예외 통일 -
String: Unicode 17.0.0, Emoji 17.0 지원,
strip계열 메서드 확장 -
Thread:
raise(cause:)인자 지원
표준 라이브러리(Stdlib) 업데이트
-
기본 젬 승격:
ostruct,pstore,benchmark,logger,rdoc,win32ole,irb,reline,fiddle등 -
기본 젬 추가:
win32-registry 0.1.2 -
기본 젬 업데이트:
RubyGems 4.0.3,bundler 4.0.3,openssl 4.0.0,json 2.18.0등 -
번들 젬 업데이트:
minitest 6.0.0,rake 13.3.1,rbs 3.10.0,debug 1.11.1등 - RubyGems/Bundler 4 포함
플랫폼 지원
- Windows: MSVC 14.0 미만 버전 지원 중단 (Visual Studio 2015 이상 필요)
호환성 변경
-
Ractor.yield,Ractor#take,Ractor#close_incoming,Ractor#close_outgoing제거 -
ObjectSpace._id2ref사용 중단 -
Process::Status#&,#>>제거 - 내부 프레임(backtrace) 출력 단순화
-
ArgumentError백트레이스에 수신자 클래스/모듈명 표시
표준 라이브러리 호환성
-
CGI 라이브러리 제거,
cgi/escape만 유지 -
Set의 코어 승격으로SortedSet은 별도 젬 설치 필요 -
Net::HTTP의 자동Content-Type헤더 설정 제거
C API 업데이트
-
rb_thread_fd_close비활성화 및rb_io_close사용 권장 -
rb_thread_call_with_gvl이 GVL 유무에 관계없이 동작 -
Set용 C API 추가 (
rb_set_new,rb_set_add,rb_set_delete등)
구현 및 성능 개선
-
Class#new호출 속도 향상, 특히 키워드 인자 사용 시 - GC 힙 풀 독립 성장으로 메모리 사용량 감소
- 대형 객체 스위핑 속도 향상
-
object_id,hash계산 및 인스턴스 변수 접근 최적화 -
Ractor 성능 개선
- 락 없는 해시 구조, 캐시 경합 감소, 객체 할당 최적화
- 데드락, 인코딩, GC 관련 버그 수정
JIT 관련
-
ZJIT: 메서드 기반 JIT, Rust 1.85.0 이상 필요,
--zjit또는RubyVM::ZJIT.enable로 활성화 -
YJIT: 통계 옵션 변경,
mem_size:및call_threshold:추가 -
RJIT:
--rjit제거, 별도 저장소로 이전
변경 규모
- Ruby 3.4.0 대비 3,889개 파일 변경, 230,769줄 추가, 297,003줄 삭제
- 루비 4.0은 성능, 병렬성, 언어 일관성을 대폭 강화한 메이저 릴리스
다운로드
-
ruby-4.0.0.tar.gz,ruby-4.0.0.tar.xz,ruby-4.0.0.zip형식 제공 - 각 파일의 SHA1, SHA256, SHA512 해시값 명시
Ruby 소개
- 루비는 1993년 마츠모토 유키히로(Matz) 가 개발한 오픈소스 언어
- 다중 플랫폼에서 실행되며, 특히 웹 개발 분야에서 전 세계적으로 사용
Hacker News 의견들
-
루비 생일 축하함!
사람들이 흔히 “루비는 타이핑이 안 돼서 떠났다”라고 하지만, 이제는 RBS가 표준으로 자리 잡는 중임. Sorbet도 이를 지원하고, 코드 옆에 바로 타입을 적는 inline notation도 생김.
또 “루비는 LSP가 약하다”는 말도 이제 옛말임. ruby-lsp가 표준이 되었고, “go to definition”도 지원함. 플러그인 아키텍처 덕분에 여러 툴이 같은 AST를 재사용할 수 있음.
병렬성도 Ractor 덕분에 많이 개선되었고, 이제는 GC만 좀 더 다듬으면 완전 실험 단계를 벗어날 듯함.
ZJIT나 Box 같은 새 기능도 있지만, 아직 프로덕션에서는 권장되지 않음. 그래도 점점 나아지고 있음.
문법이 급격히 바뀌지 않는 것도 좋은 점이라 생각함- 나는 꽤 하드코어 루비스트인데 ruby-lsp는 정말 훌륭함. 하지만 RBS가 표준이 되고 있다고 보긴 어려움. 실제로는 채택률이 매우 낮음. rbs-inline은 개인 프로젝트 수준이고 활동도 적음. 다만 그 개발자가 RBS에 직접 통합하려는 시도는 반가움. 개인적으로는 주석 기반 타입 시스템이 널리 퍼질 것 같진 않음
- 루비는 그냥 파이썬보다 열등함. 더 빠르고 커뮤니티도 큰 거의 동일한 시스템이 있는데 굳이 루비를 쓸 이유가 없음
-
크리스마스엔 항상 새 루비 버전이 나와야 함.
이번엔 ruby::box가 흥미로움. 기능 롤아웃을 두 버전 동시에 돌릴 수 있게 해줌.
그리고 여러 줄에 걸쳐if condition1 && condition2를 쓸 수 있게 된 것도 꽤 멋짐- 언젠가 각 Ractor가 자기만의 ruby::box에서 실행되고, 각 box가 독립적으로 GC를 돌릴 수 있으면 좋겠음. 그러면 BEAM처럼 진짜 병렬 실행이 가능해질 것임. p99 지연도 줄어들겠지. 물론 객체 공유 시 복사 비용이 생기겠지만 대부분의 앱에선 미미할 듯함
- 나는 이미 예전부터
if condition1 && condition2를 여러 줄로 써왔는데 잘 작동했음. 새 문법이 뭐가 다른지 모르겠음
-
루비 4.0 출시가 반갑지만, 2025년에 나는 완전히 파이썬으로 전환했음.
Claude Code가 내 루비 프로젝트를 100% 파이썬으로 자동 변환해줬고, 그 이후로 루비를 쓸 이유가 사라졌음.
10년 넘게 루비를 사랑했고 책도 썼지만, 이제는 fastapi, pytorch, langchain, streamlit 같은 생태계 덕분에 파이썬이 승리했음. 그래도 루비의 문법은 여전히 가장 아름답다고 생각함- 네가 언급한 건 전부 파이썬 생태계의 라이브러리이지 언어 자체의 장점은 아님. 많은 개발자가 언어보다는 라이브러리 때문에 파이썬으로 옮기고 있음. 그 결과 파이썬은 여러 방향으로 끌려가며 점점 언어 철학이 흐려지는 문제가 생김. 반면 루비는 언어 자체를 좋아하는 사람들이 모여 있어서 본질을 잘 지키고 있음
- 나도 올해 루비에서 Kotlin으로 옮겼음. 정적 타이핑이 없다는 불안감이 너무 컸음. Kotlin은 성능도 좋고, 메모리만 조금 더 쓰는 건 이제 큰 문제가 아님. 루비는 여전히 좋아하지만 간단한 스크립트에만 씀
- 파이썬은 IDE 지원이 훨씬 좋아서 그 이유만으로도 옮길 가치가 있었음. 루비의 과도한 동적성은 내 취향이 아님
- Langchain을 써보려 했는데 너무 빠르게 변해서 문서가 전혀 따라가지 못함. 검색하면 “왜 Langchain 문서가 엉망인가”라는 글만 잔뜩 나옴. 그래서 Haystack으로 바꿨는데 훨씬 만족스러움
- 나도 pandas, numpy, pytorch를 좋아하지만 여전히 Rails로 풀스택 웹앱을 만드는 게 즐거움. 그래서 pyCall을 정말 사랑함
-
크리스마스엔 역시 새 루비 버전이 빠질 수 없음. Matz와 팀에게 감사함
-
2025~26년에 루비를 배우려는 사람에게 추천할 만한 최신 자료가 있을까? 공식 문서 외에 괜찮은 책이 궁금함
- 나는 Pragmatic Studio의 Elixir와 Erlang 강좌를 들었는데 퀄리티가 매우 높았음. 같은 곳에서 루비와 Rails 강좌도 제공함
Pragmatic Studio Ruby on Rails 강좌
- 나는 Pragmatic Studio의 Elixir와 Erlang 강좌를 들었는데 퀄리티가 매우 높았음. 같은 곳에서 루비와 Rails 강좌도 제공함
-
루비는 정말 놀라운 언어임. 최근에 Rails 위에 Markdown 파일 하나로 API를 생성하는 레이어를 만들었는데, 파이썬으로 같은 걸 하려면 훨씬 복잡했음. 자바스크립트로는 더 끔찍했을 것임. 루비의 메타프로그래밍 능력은 정말 독보적임
- 흥미로운데, 혹시 예시를 볼 수 있을까?
-
내부 스택 트레이스가 정리된 게 반가움. 언젠가 상대 경로도 지원되면 좋겠음. 그리고 Set이 드디어 제대로 대접받는 것도 좋음
- 스택 트레이스에 상대 경로가 나오면 정말 좋을 것 같음
-
지금은 루비를 쓰지 않는 회사에서 일하지만 여전히 루비를 깊이 사랑함. 이번 릴리스에 감사하고, 다시 쓸 기회가 생기길 바람
-
예전에 Ruby::Box(네임스페이스) 기능이 심각한 성능 저하를 일으킨다고 들었는데, 이번에 개선됐는지 궁금함
-
툴링이 개선됐는지 알고 싶음. 아직 Windows에서 LSP를 제대로 돌려본 적이 없음
- 내 생각엔 Windows에서 프로그래밍하는 건 고통 자초임. Microsoft 언어가 아니라면 Linux나 macOS가 훨씬 나음
- 루비의 개발자 경험(DX) 은 기대 이하이고, 특히 Windows에서는 더 나쁨. 다행히 이 문제를 인식하고 개선하려는 발표가 있었음
- WSL2를 써봤는지?