예전에 MacRuby가 LLVM을 이용해 macOS에서 네이티브 코드로 컴파일되고, Objective‑C 프레임워크와 통합되던 시절이 있었음
꽤 멋진 아이디어였는데, 결국 Apple이 Swift로 방향을 바꾼 듯함
새 버전이 나오면 Ruby Under a Microscope 책을 꼭 사서 읽어볼 생각임. Ruby는 여전히 좋아하지만 실제로 쓸 기회가 많지 않았음
MacRuby의 제작자가 Apple을 떠난 뒤 RubyMotion을 만들었음
지금은 다른 사람들이 이어가고 있지만, 현재는 DragonRuby(게임 중심 Ruby 구현체)에 더 집중하는 분위기임
지금도 Objective‑C를 써서 macOS, iOS, iPadOS용 앱을 만들 수 있음
다만 예전 API들은 더 이상 지원되지 않을 수도 있음
여러 언어를 다뤄온 입장에서 보면, Apple이 Swift로 옮긴 건 마치 Microsoft가 VB6에서 VB.Net으로 넘어간 것과 비슷한 느낌임
VB6은 개발 속도가 정말 빨랐고, Direct3D나 ASP Classic까지 다룰 수 있었음
Ruby의 우아함과 개발 편의성이 그 시절을 떠올리게 함
만약 Ruby에 VB6 수준의 GUI 도구가 있었다면 인기도 꽤 달랐을 것 같음
Pat이 계속해서 프로젝트를 이어가는 걸 보니 정말 반가움
그의 첫 Ruby Under a Microscope 책과 블로그 글들은 내게 큰 영감을 줬음
예전에 Euruko 컨퍼런스에서 직접 만난 적도 있는데, 정말 훌륭한 사람이었음
따뜻한 댓글에 감사함
처음 Ruby Under a Microscope를 읽었을 때 정말 재미있었음
그 덕분에 예전에 CTF 문제 풀이에도 활용했음
요즘 Ruby 내부 구현을 따라가진 못했지만, 새 버전이 나오면 꼭 살 생각임
2002년부터 2010년까지 Ruby를 많이 썼는데, 이후엔 거의 손을 놓았음
이번 글을 보고 새 버전 책을 다시 읽고 싶어졌음
Ruby 컴파일 얘기가 나와서 말인데, Stripe 개발자들이 만든 Sorbet compiler를 써본 적 있는지 궁금함 Sorbet Compiler 공개 글
지금은 저장소에서 사라졌고, 더 이상 개발되지 않는 듯해서 아쉬움 AOT 컴파일은 Ruby에선 정말 어려움
Sorbet의 접근이 흥미로운 이유는 Ruby의 타입 검사를 기반으로 빠른 경로를 만들 수 있기 때문임
나도 개인 프로젝트로 Ruby 컴파일러를 만들고 있는데, hokstad.com/compiler와 writing-a-compiler-in-ruby를 참고하고 있음
지금은 RubySpec 통과에 집중하고 있고, 나중엔 타입 기반 최적화도 시도해볼 생각임
MRuby를 알게 된 이후로, 내 프로젝트와 스크립트를 독립 실행 파일로 바꾸는 재미에 빠져 있음
Ruby Under a Microscope가 여전히 업데이트되고 있어서 기쁨
Ruby 내부 동작을 이해하려는 사람에게는 필독서라고 생각함
YJIT 블록이 여러 번 실행될 때, 입력 타입별로 어떻게 컴파일을 추적하는지 궁금했음
Ruby가 int나 float 등 다양한 타입을 어떻게 처리하는지 알고 싶음
그게 바로 YJIT의 핵심임
실제 타입이 제공될 때까지 컴파일을 미루는 “wait‑and‑see” 접근을 사용함
각 타입별로 블록 버전을 따로 관리하고, 상황에 맞게 호출함
이 알고리즘은 Basic Block Versioning이라 불림
Shopify의 Maxime Chevalier‑Boisvert가 RubyConf 2021 발표 영상에서 잘 설명함
새 JIT 엔진인 ZJIT는 다른 방식을 쓰는 것으로 보임
동적 타입 언어를 JIT으로 빠르게 만드는 건 보통 메모리 사용량 증가라는 대가를 치름
Shopify 같은 대형 기업이 아니라면 이게 더 큰 문제일 수 있음
하지만 작은 기업은 보통 애플리케이션 규모도 작음
요즘 클라우드 인스턴스는 코어당 4GiB 정도 메모리를 주기 때문에, 수백 MB의 JIT 코드 정도는 충분히 감당 가능함
YJIT이 함수 호출 횟수만 세서 핫스팟을 찾는 방식이 단순해 보였음
JavaScript JIT처럼 루프 내부의 무거운 연산을 감지하는 기능은 없을까 궁금했음
Ruby의 블록 구조가 이런 최적화에 도움이 될 수도 있을 것 같음
맞음, Ruby는 루프 본문을 블록으로 처리하기 때문에
JIT이 블록을 별도 함수처럼 다루면서 반복문을 자연스럽게 최적화할 수 있음
이 부분은 다음 장에서 더 깊이 다뤄볼 예정임
Hacker News 의견
예전에 MacRuby가 LLVM을 이용해 macOS에서 네이티브 코드로 컴파일되고, Objective‑C 프레임워크와 통합되던 시절이 있었음
꽤 멋진 아이디어였는데, 결국 Apple이 Swift로 방향을 바꾼 듯함
새 버전이 나오면 Ruby Under a Microscope 책을 꼭 사서 읽어볼 생각임. Ruby는 여전히 좋아하지만 실제로 쓸 기회가 많지 않았음
지금은 다른 사람들이 이어가고 있지만, 현재는 DragonRuby(게임 중심 Ruby 구현체)에 더 집중하는 분위기임
참고로 위키 문서도 있음
다만 예전 API들은 더 이상 지원되지 않을 수도 있음
VB6은 개발 속도가 정말 빨랐고, Direct3D나 ASP Classic까지 다룰 수 있었음
Ruby의 우아함과 개발 편의성이 그 시절을 떠올리게 함
만약 Ruby에 VB6 수준의 GUI 도구가 있었다면 인기도 꽤 달랐을 것 같음
Pat이 계속해서 프로젝트를 이어가는 걸 보니 정말 반가움
그의 첫 Ruby Under a Microscope 책과 블로그 글들은 내게 큰 영감을 줬음
예전에 Euruko 컨퍼런스에서 직접 만난 적도 있는데, 정말 훌륭한 사람이었음
처음 Ruby Under a Microscope를 읽었을 때 정말 재미있었음
그 덕분에 예전에 CTF 문제 풀이에도 활용했음
요즘 Ruby 내부 구현을 따라가진 못했지만, 새 버전이 나오면 꼭 살 생각임
이번 글을 보고 새 버전 책을 다시 읽고 싶어졌음
Ruby 컴파일 얘기가 나와서 말인데, Stripe 개발자들이 만든 Sorbet compiler를 써본 적 있는지 궁금함
Sorbet Compiler 공개 글
AOT 컴파일은 Ruby에선 정말 어려움
Sorbet의 접근이 흥미로운 이유는 Ruby의 타입 검사를 기반으로 빠른 경로를 만들 수 있기 때문임
나도 개인 프로젝트로 Ruby 컴파일러를 만들고 있는데, hokstad.com/compiler와
writing-a-compiler-in-ruby를 참고하고 있음
지금은 RubySpec 통과에 집중하고 있고, 나중엔 타입 기반 최적화도 시도해볼 생각임
Ruby 컴파일과는 직접 관련 없지만, Enterprise Integration with Ruby 책이 웹 외의 영역에서 Ruby를 활용하는 데 큰 통찰을 줬음
MRuby를 알게 된 이후로, 내 프로젝트와 스크립트를 독립 실행 파일로 바꾸는 재미에 빠져 있음
Ruby Under a Microscope가 여전히 업데이트되고 있어서 기쁨
Ruby 내부 동작을 이해하려는 사람에게는 필독서라고 생각함
YJIT 블록이 여러 번 실행될 때, 입력 타입별로 어떻게 컴파일을 추적하는지 궁금했음
Ruby가 int나 float 등 다양한 타입을 어떻게 처리하는지 알고 싶음
실제 타입이 제공될 때까지 컴파일을 미루는 “wait‑and‑see” 접근을 사용함
각 타입별로 블록 버전을 따로 관리하고, 상황에 맞게 호출함
이 알고리즘은 Basic Block Versioning이라 불림
Shopify의 Maxime Chevalier‑Boisvert가 RubyConf 2021 발표 영상에서 잘 설명함
새 JIT 엔진인 ZJIT는 다른 방식을 쓰는 것으로 보임
동적 타입 언어를 JIT으로 빠르게 만드는 건 보통 메모리 사용량 증가라는 대가를 치름
Shopify 같은 대형 기업이 아니라면 이게 더 큰 문제일 수 있음
요즘 클라우드 인스턴스는 코어당 4GiB 정도 메모리를 주기 때문에, 수백 MB의 JIT 코드 정도는 충분히 감당 가능함
YJIT이 함수 호출 횟수만 세서 핫스팟을 찾는 방식이 단순해 보였음
JavaScript JIT처럼 루프 내부의 무거운 연산을 감지하는 기능은 없을까 궁금했음
Ruby의 블록 구조가 이런 최적화에 도움이 될 수도 있을 것 같음
JIT이 블록을 별도 함수처럼 다루면서 반복문을 자연스럽게 최적화할 수 있음
이 부분은 다음 장에서 더 깊이 다뤄볼 예정임