나는 Ruby를 싫어하는 이유로 자주 나오는 Twitter 사례가 부적절하다고 생각함
Ruby가 원인이었다 하더라도, 그 선택 덕분에 사업이 시작되고 첫 성공을 거둘 수 있었음
Twitter의 문제는 언어 때문이 아니라 대규모 팬아웃(celebrity tweet → 수백만 팔로워) 이라는 특수한 상황 때문이었음
또, “처음부터 확장 가능한” 언어를 썼지만 실패한 스타트업들은 아무도 이야기하지 않음 — 전형적인 생존자 편향임 Wired의 해당 작가 페이지를 보면 논란을 유발하는 글쓰기를 전략적으로 하는 듯함
나는 여전히 Ruby로 유용한 소프트웨어를 만드는 조용한 다수 중 하나로 돌아감
“Ruby가 아니었다면 더 나은 언어로 같은 사업을 시작해도 문제를 피할 수 있었을 것”이라는 반론도 있음
시간이 많이 흘렀고, 지금의 Ruby는 그때와 완전히 다름
원문 기사에서는 저자가 Ruby를 싫어한 이유를 구체적으로 설명하지 않았음
단지 과거의 한계를 나열했을 뿐이며, 실제로는 자신이 맡은 코드베이스의 문제였을 가능성이 큼
첫 번째 글의 핵심은 “2025년에 Ruby를 새로 선택할 이유는 없다”였고, 그게 논의의 중심이 되었어야 함
이번 글은 감정에 호소하는 방향으로 갔고, 아이러니하게도 Ruby가 감성으로 움직인다는 전 글의 주장을 스스로 입증한 셈임
Elixir를 좋아하는 사람들 중 다수가 Ruby를 ‘비진지하다’고 보지만, Elixir 역시 Ruby의 영향을 강하게 받았음
나는 Elixir를 여러 해 써왔고, 초반에는 Ruby도 했음
많은 사람들이 Ruby의 친숙한 문법과 함수형 기반을 결합한 Elixir에 끌림
특히 BEAM 런타임 덕분에 운영 특성이 완전히 다름
BEAM은 단순한 언어가 아니라 시스템을 위한 시스템이라는 느낌을 줌 — 모든 것을 추적, 재시작, 관찰할 수 있음
Ruby에서 영감을 받은 컴파일 언어 Crystal이 언급되지 않은 게 의외였음
다만 Crystal은 Elixir보다 인기도 부족 문제가 더 심함 TIOBE 순위 기준으로 Elixir는 상위 50위 안에 있음
macOS에는 Ruby가 기본 설치되어 있어서, 별도 설치 없이 스크립트를 짜려면 Perl, Bash, AppleScript 아니면 Ruby를 써야 함
두 기사 모두 실속이 없다고 느낌
첫 글은 StackOverflow 통계와 Twitter 얘기만 하고, 두 번째 글은 그저 향수와 미학 이야기뿐임
LLM이 아니라 사람이 쓴 글이라는 게 오히려 더 우울함
내가 좋아하는 언어를 판단하는 기준은 “이 언어로 코드를 쓰는 걸 좋아하느냐”가 아니라
“운영 중인 시스템이 이 언어로 작성되어 있기를 바라느냐”임
두 질문의 답이 같은 사람은 많지 않음
코드 작성과 비즈니스 운영은 별개의 문제임
나는 Ocaml을 좋아하지만, 생태계가 약하고 인력 확보가 어려워서 운영 시스템에는 쓰고 싶지 않음
언어의 시대와 팀의 코딩 문화에 따라 다름
타입 주석과 검사 도구가 있는 Python은 유지보수하기 좋지만, 그렇지 않다면 문서화 문화가 필수임
시스템을 단순히 유지할지, 계속 발전시킬지에 따라 답이 달라짐
전자라면 COBOL, 후자라면 다른 선택이 흥미로워짐
내가 직접 만든 시스템이라면 어떤 언어든 괜찮음, 아니면 다른 사람에게 넘기겠음
Forth로 코딩하는 건 즐기지만, 그걸로 생업을 하고 싶지는 않음
나는 Ruby를 정말 좋아함
감성 때문이 아니라, 단순히 작성하는 즐거움이 큼 — 특히 JavaScript보다 훨씬 즐거움
Ruby를 공격하는 글들은 이상하게 느껴짐
Github, Twitter, Coinbase, Shopify 같은 성공 사례가 있는데, 확장성 문제는 성공의 부산물일 뿐임
Ruby는 훌륭한 도구이며, 다음 프로젝트에서 적합한지 직접 판단해보길 권함
원문 기사도, 그에 대한 반박도 정의가 불분명함
“Ruby는 영원히 확장되지 않는다”는 주장이라면 대부분의 언어도 마찬가지임
결국 두 글 모두 “Ruby는 영원히 동작하지 않는다”는 점에서는 일치함
흥미로운 건, 원문이 Ruby의 StackOverflow 순위를 18위라고 깎아내리면서
실제로는 2024년 기준 14위이고, 자신이 칭찬한 Scala는 그보다 9단계 아래라는 점임 StackOverflow 2024 설문 링크
“Ruby는 영원히 동작하지 않는다”는 말에 동의하지 않음
내가 10년 전에 쓴 Ruby 코드, 예를 들어 WebKit의 offlineasm 컴파일러는 아직도 잘 돌아감
Java를 비꼬면서 Scala를 칭찬하는 것도 웃김 — Scala의 강점 대부분은 Java 덕분임
많은 사람들이 Ruby를 “인간을 위한 언어”라고 표현하지만, 사실 모든 언어는 인간을 위해 만들어졌음
Ruby는 문법이 깔끔하고 표현력이 좋지만, 동적 타이핑과 매직(암묵적 동작) 때문에 쓰기 어렵게 느껴짐
나에게는 맞지 않지만, 어떤 사람들에게는 완벽히 맞는 언어임
Rails가 “마법 같은 객체” 개념을 대중화했음
팬들은 이를 놀랍고 즐겁다고 하지만, 어떤 사람에게는 무섭게 느껴짐
Python의 Flask도 비슷하게 context local proxy를 사용함
반면 Zig나 Go는 “모든 것은 명시적이어야 한다”는 반발로 등장했고, Rust는 그 중간쯤에 위치함
Rust는 엄격하지만, DSL 같은 표현력을 깨끗하게 제공함
나는 10년 전 Ruby에서 Elixir로 전환했음
알고리즘 성능이 10배 향상되었고, 불변성 덕분에 버그가 줄었으며, 동시성 지원도 훌륭했음
패턴 매칭과 가드 덕분에 보일러플레이트가 사라졌고, GIL이 없고 프로세스별 GC가 있음
학습 곡선은 약간 있지만, Elixir는 장기 유지보수나 부하 측면에서 훨씬 잘 확장됨
Ruby 커뮤니티는 여전히 훌륭함
단지 Elixir가 네이티브 실행 파일로 컴파일되거나 브라우저에서 돌 수 있으면 좋겠음
나도 비슷한 경험을 했음
여전히 “Ruby로 사고”하지만, 개인 프로젝트는 Elixir/Erlang으로 함
회사에서는 Golang과 Python을 쓰지만 즐겁지 않음
개인 스크립트는 여전히 Ruby로 작성함
이 글은 마치 누군가 자기 언어를 방어하는 느낌임
인기나 익숙함보다, 언어의 특성이 코드 품질에 미치는 영향을 냉정하게 분석하는 논의가 더 가치 있다고 생각함
그런 논의는 종종 모나드나 어플리커티브 같은 개념 때문에 사람들을 멀어지게 하지만, 그게 진짜 유익한 토론임
코드 품질, 생산성, 안정성은 객관적으로 측정하기 어려워서 결국 경험의 차이로 귀결됨
코드 품질만이 아니라 단순성, 가독성, 표현 속도도 중요함
타입과 제약이 많을수록 품질은 올라가지만, 개발 속도와 유연성은 떨어짐
Hacker News 의견
Ruby가 원인이었다 하더라도, 그 선택 덕분에 사업이 시작되고 첫 성공을 거둘 수 있었음
Twitter의 문제는 언어 때문이 아니라 대규모 팬아웃(celebrity tweet → 수백만 팔로워) 이라는 특수한 상황 때문이었음
또, “처음부터 확장 가능한” 언어를 썼지만 실패한 스타트업들은 아무도 이야기하지 않음 — 전형적인 생존자 편향임
Wired의 해당 작가 페이지를 보면 논란을 유발하는 글쓰기를 전략적으로 하는 듯함
나는 여전히 Ruby로 유용한 소프트웨어를 만드는 조용한 다수 중 하나로 돌아감
단지 과거의 한계를 나열했을 뿐이며, 실제로는 자신이 맡은 코드베이스의 문제였을 가능성이 큼
첫 번째 글의 핵심은 “2025년에 Ruby를 새로 선택할 이유는 없다”였고, 그게 논의의 중심이 되었어야 함
이번 글은 감정에 호소하는 방향으로 갔고, 아이러니하게도 Ruby가 감성으로 움직인다는 전 글의 주장을 스스로 입증한 셈임
Elixir를 좋아하는 사람들 중 다수가 Ruby를 ‘비진지하다’고 보지만, Elixir 역시 Ruby의 영향을 강하게 받았음
많은 사람들이 Ruby의 친숙한 문법과 함수형 기반을 결합한 Elixir에 끌림
특히 BEAM 런타임 덕분에 운영 특성이 완전히 다름
BEAM은 단순한 언어가 아니라 시스템을 위한 시스템이라는 느낌을 줌 — 모든 것을 추적, 재시작, 관찰할 수 있음
다만 Crystal은 Elixir보다 인기도 부족 문제가 더 심함
TIOBE 순위 기준으로 Elixir는 상위 50위 안에 있음
첫 글은 StackOverflow 통계와 Twitter 얘기만 하고, 두 번째 글은 그저 향수와 미학 이야기뿐임
LLM이 아니라 사람이 쓴 글이라는 게 오히려 더 우울함
“운영 중인 시스템이 이 언어로 작성되어 있기를 바라느냐”임
두 질문의 답이 같은 사람은 많지 않음
나는 Ocaml을 좋아하지만, 생태계가 약하고 인력 확보가 어려워서 운영 시스템에는 쓰고 싶지 않음
타입 주석과 검사 도구가 있는 Python은 유지보수하기 좋지만, 그렇지 않다면 문서화 문화가 필수임
전자라면 COBOL, 후자라면 다른 선택이 흥미로워짐
감성 때문이 아니라, 단순히 작성하는 즐거움이 큼 — 특히 JavaScript보다 훨씬 즐거움
Ruby를 공격하는 글들은 이상하게 느껴짐
Github, Twitter, Coinbase, Shopify 같은 성공 사례가 있는데, 확장성 문제는 성공의 부산물일 뿐임
Ruby는 훌륭한 도구이며, 다음 프로젝트에서 적합한지 직접 판단해보길 권함
“Ruby는 영원히 확장되지 않는다”는 주장이라면 대부분의 언어도 마찬가지임
결국 두 글 모두 “Ruby는 영원히 동작하지 않는다”는 점에서는 일치함
흥미로운 건, 원문이 Ruby의 StackOverflow 순위를 18위라고 깎아내리면서
실제로는 2024년 기준 14위이고, 자신이 칭찬한 Scala는 그보다 9단계 아래라는 점임
StackOverflow 2024 설문 링크
내가 10년 전에 쓴 Ruby 코드, 예를 들어 WebKit의 offlineasm 컴파일러는 아직도 잘 돌아감
Ruby는 문법이 깔끔하고 표현력이 좋지만, 동적 타이핑과 매직(암묵적 동작) 때문에 쓰기 어렵게 느껴짐
나에게는 맞지 않지만, 어떤 사람들에게는 완벽히 맞는 언어임
팬들은 이를 놀랍고 즐겁다고 하지만, 어떤 사람에게는 무섭게 느껴짐
Python의 Flask도 비슷하게 context local proxy를 사용함
반면 Zig나 Go는 “모든 것은 명시적이어야 한다”는 반발로 등장했고, Rust는 그 중간쯤에 위치함
Rust는 엄격하지만, DSL 같은 표현력을 깨끗하게 제공함
알고리즘 성능이 10배 향상되었고, 불변성 덕분에 버그가 줄었으며, 동시성 지원도 훌륭했음
패턴 매칭과 가드 덕분에 보일러플레이트가 사라졌고, GIL이 없고 프로세스별 GC가 있음
학습 곡선은 약간 있지만, Elixir는 장기 유지보수나 부하 측면에서 훨씬 잘 확장됨
Ruby 커뮤니티는 여전히 훌륭함
단지 Elixir가 네이티브 실행 파일로 컴파일되거나 브라우저에서 돌 수 있으면 좋겠음
여전히 “Ruby로 사고”하지만, 개인 프로젝트는 Elixir/Erlang으로 함
회사에서는 Golang과 Python을 쓰지만 즐겁지 않음
개인 스크립트는 여전히 Ruby로 작성함
인기나 익숙함보다, 언어의 특성이 코드 품질에 미치는 영향을 냉정하게 분석하는 논의가 더 가치 있다고 생각함
그런 논의는 종종 모나드나 어플리커티브 같은 개념 때문에 사람들을 멀어지게 하지만, 그게 진짜 유익한 토론임
타입과 제약이 많을수록 품질은 올라가지만, 개발 속도와 유연성은 떨어짐
이런 글은 HN에서 언어 싸움을 유발하는 독소 같은 존재임
진지하게 받아들일 필요 없음
하지만 지금은 Kotlin이 더 잘 맞음 — 정적 타이핑과 문법의 인체공학적 설계 덕분임
Ruby는 프로젝트가 커질수록 불안하지만, 여전히 작은 작업에는 사랑스러운 언어임
언어 탓이 아닐 수도 있지만, 안전장치가 적은 언어일수록 위험한 코드가 모이는 경향이 있음
if.class를 실행해보면 완전히 그렇지는 않음그래도 대중 언어 중에서는 가장 가까운 수준임