5P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 루비 4.0.0이 공개되어, 새로운 Ruby BoxZJIT를 도입하고 다수의 성능 및 언어 개선을 포함
  • Ruby Box는 클래스, 모듈, 전역 변수, 네이티브/루비 라이브러리 정의를 격리 실행할 수 있는 실험적 기능
  • ZJIT는 Rust 기반 차세대 JIT 컴파일러로, 기존 YJIT보다 구조적으로 확장 가능하며 외부 기여를 용이하게 함
  • Ractor 병렬 실행 모델이 안정성과 성능 면에서 개선되어, 향후 실험적 상태를 해제할 예정
  • 핵심 클래스, 표준 라이브러리, C API, GC, JIT 등 전반에 걸친 업데이트로 루비 생태계의 성능과 확장성을 강화

Ruby 4.0 개요

  • Ruby 4.0.0은 Ruby BoxZJIT를 중심으로 한 대규모 업데이트 버전
  • 병렬 실행, 언어 문법, 표준 라이브러리, 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 기반의 더 큰 컴파일 단위를 지원하며, 외부 기여를 촉진하는 구조
  • 현재 인터프리터보다 빠르지만 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: producesize: 키워드 인자 추가
  • 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 강좌
  • 루비는 정말 놀라운 언어임. 최근에 Rails 위에 Markdown 파일 하나로 API를 생성하는 레이어를 만들었는데, 파이썬으로 같은 걸 하려면 훨씬 복잡했음. 자바스크립트로는 더 끔찍했을 것임. 루비의 메타프로그래밍 능력은 정말 독보적임

    • 흥미로운데, 혹시 예시를 볼 수 있을까?
  • 내부 스택 트레이스가 정리된 게 반가움. 언젠가 상대 경로도 지원되면 좋겠음. 그리고 Set이 드디어 제대로 대접받는 것도 좋음

    • 스택 트레이스에 상대 경로가 나오면 정말 좋을 것 같음
  • 지금은 루비를 쓰지 않는 회사에서 일하지만 여전히 루비를 깊이 사랑함. 이번 릴리스에 감사하고, 다시 쓸 기회가 생기길 바람

  • 예전에 Ruby::Box(네임스페이스) 기능이 심각한 성능 저하를 일으킨다고 들었는데, 이번에 개선됐는지 궁금함

  • 툴링이 개선됐는지 알고 싶음. 아직 Windows에서 LSP를 제대로 돌려본 적이 없음

    • 내 생각엔 Windows에서 프로그래밍하는 건 고통 자초임. Microsoft 언어가 아니라면 Linux나 macOS가 훨씬 나음
    • 루비의 개발자 경험(DX) 은 기대 이하이고, 특히 Windows에서는 더 나쁨. 다행히 이 문제를 인식하고 개선하려는 발표가 있었음
    • WSL2를 써봤는지?