Hacker News 의견

• 루비 언어의 표현력에 대한 의견이 분분함

  루비는 생태계 내부에서 또는 생태계가 기대하는 작업을 할 때는 훌륭하지만, 비표준적인 작업을 하려고 할 때는 매우 까다로움. 지원 기능 메소드가 5단계 추상화 깊이 어딘가에 정의되어 있을 수 있으며, 때로는 어떤 라이브러리의 메타프로그래밍 일부일 수도 있어 LSP가 가리키지 못하는 경우도 있음. 루비는 암시적인 것을 축하하는 생태계로, 이는 때때로 미칠 듯한 느낌을 줌. 완성된 코드가 멋지고 읽기 좋다고 해도 이것이 모든 문제를 해결해주지는 않음.

• 개발자 경험에 대한 중요성을 인정하면서도 루비가 최고는 아니라는 의견

  개발자 경험이 많은 프로그래밍 언어나 프레임워크에서 과소평가되고 있다는 점에 동의하지만, 루비가 이 분야에서 최고라고 생각하지는 않음. 문법이 처음에는 좋아 보일 수 있지만, 타입 정보의 부재와 메타프로그래밍은 루비를 사용하기 어렵게 만듦. 또한 프로그래밍 언어를 선택할 때 고려해야 할 다른 요소들이 있음, 예를 들어 런타임 성능 등이 있음. 정적 타이핑의 부재와 이러한 이유들로 루비가 유행에서 빠진 것 같음. 개인적으로 코틀린이 프로그래밍 언어에서 이상적인 지점이라고 생각함. 코틀린은 간결하고 읽기 쉬운 언어로, 세계적 수준의 도구 지원, 정적 타이핑, JVM의 우수한 성능과 자바 생태계의 모든 것을 제공함.

• 루비 언어에 대한 애정을 표현하면서도 파이썬을 선호하는 이유를 설명하는 의견

  루비를 좋아하며, 파이썬보다 루비를 더 선호함. 특히 함수형 연산의 연쇄가 매우 깔끔하고 표현력이 뛰어남. 자바 스트림과 비슷한 점을 좋아함. 라이브러리 생태계도 훌륭하며, 파이썬과 유사하게 라이브러리가 매우 실용적임. 하지만 유지보수가 필요한 작업에는 파이썬을, 성능에 조금이라도 신경을 써야 할 때는 자바를 선택함. 루비와 파이썬 사이에서는 점진적 타이핑에 대한 다른 접근 방식 때문에 계속 파이썬을 선택함. 파이썬3는 타입을 프로그램의 일부로 포함시킬 수 있지만, 루비는 타입을 별도의 파일로 두는 경향이 있음. 이는 주로 라이브러리를 위한 것으로 보이며, 자바스크립트 라이브러리가 타입스크립트 타입 파일을 함께 제공하는 것과 유사함. 하지만 개인적으로는 타입을 직접 사용하고 싶음. 물론 Sorbet이라는 도구가 있지만, 이것이 젬(gem)이라는 점과 문법의 일부가 아니라 언어 내에서 동작한다는 점이 마음에 들지 않음. Stripe에서 잘 작동하는 것을 보았지만 개인적으로는 좋아하지 않으며, 내장된 타입 힌팅을 가진 파이썬3이 루비보다 타입을 더 쉽게 적용할 수 있다고 느낌. 루비를 매우 좋아하지만 타입 힌팅 부분이 개선되기를 바람.

• 다양한 언어에 대한 경험을 공유하며 루비에 대한 선호도가 낮다는 의견

  다양한 언어를 시도해봤고, 한때 레일즈를 주로 사용할 때 루비에 깊이 몰두했음. 그러나 루비는 아마도 가장 좋아하지 않는 언어임. 루비를 독특하게 만드는 대부분의 기능이 오히려 F#으로 기능적인 즐거움을 찾거나, 모험을 느끼고 싶을 때 C++을 사용하거나, 동적 언어를 원할 때는 Scheme/Racket을 사용하도록 유도함. 프로그래밍 언어의 표현력에 대한 일반적으로 인정받는 정량적 정의가 있는지 궁금함. 여기서 저자는 표현력을 자연 언어에 가까움으로 동일시하는 것 같음. 경험상, 루비 코드는 작성하기 쉽지만 코드 베이스와 그 이디엄에 익숙하지 않으면 따라가기 어려움. 이해하는 데 필요한 많은 정보가 암시적인 맥락을 통해 전달됨.

• 루비에 대한 강한 반감을 표현하면서도 현재 주로 사용하는 언어임을 밝히는 의견

  루비를 열정적으로 싫어하지만, 현재 주로 사용하는 언어임. 루비 자체가 합리적인 언어라기보다는 생태계에서 흔한 패턴들이 문제임. 코드 공유를 위한 상속 사용, 전역 가변 상태의 만연, 메타프로그래밍의 남용 등이 문제로 지적됨. 이러한 문제들은 언어가 강제하는 것이 아니라 커뮤니티에서 드물게 사용하는 관습임.

• 루비 유지보수의 어려움을 토로하며 다른 언어로의 전환을 시도하는 의견

  루비 유지보수가 악몽이라고 느끼며, 그 지옥에서 벗어나려고 시도 중임. 개인 프로젝트에는 루비를 좋아하지만, 다른 사람들과 함께 작업할 때는 더 빠르게 엉망이 되고, 그로 인해 "당신의 길을 방해하지 않는다"는 루비의 장점이 사라짐. 코드에서 지역적 추론 능력을 파괴하는 것이 문제로 지적됨.

• 루비에서 러스트로 전환한 경험을 공유하며 루비에 대한 애정을 표현하는 의견

  10년간 루비를 사용한 후 4년 전에 러스트로 전환했으며, 뒤돌아보지 않을 계획임. 그럼에도 불구하고 루비에 대한 애정이 있음. 좋은 타입 시스템 없이는 더 이상 할 수 없다고 느끼며, 러스트에 익숙해진 것 같음. 그러나 루비의 강력한 리플렉션 기능이 그립다고 함.

• 즐거운 프로그래밍 언어가 종종 작은 일자리 시장을 가지고 있다는 아이러니를 지적하는 의견

  가장 즐거운 프로그래밍 언어가 종종 가장 작은 일자리 시장을 가지고 있는 것이 프로그래밍의 아이러니 중 하나임. 엘릭서를 하루 종일 프로그래밍할 수 있다면 프로그래머로서의 직업이 훨씬 나아질 것이지만, 타입스크립트, 파이썬, 자바에 비해 엘릭서 일자리는 거의 없음. 루비는 이에 대한 예외였지만, 이제는 레일즈를 기반으로 하는 사람들이 거의 없으며, 대신 리액트와 NextJS를 기반으로 하는 사람들이 많아짐. 이것은 전체 스택 애플리케이션 시장에 대한 이야기이며, 시스템용 러스트 사용자나 데이터/AI용 파이썬 사용자에게는 다를 수 있음.

• 루비 생태계와 문화가 프로그래밍에 미치는 영향을 강조하는 의견

  언어 자체에 대한 논의가 많지만, 루비 생태계와 그것이 조성하는 문화가 루비에 계속 머무르게 하는 이유임. 기사에서도 이 점을 지적함. 루비 주변의 프로그래밍 커뮤니티만큼 격려적이고 친절한 커뮤니티를 아직 보지 못함.

• 루비를 즐기는 저자에 대한 긍정적인 반응과 개인적인 경험을 공유하는 의견

  저자가 루비를 즐기는 것에 대해 기쁘게 생각하며, 루비에 대한 제한된 경험을 가진 사람으로서 이러한 인용구들이 눈에 띔. 언어가 사용하기 즐거워야 한다는 것, 잘 작성된 루비 코드가 자연 언어처럼 읽힐 수 있다는 것, 프로그래밍하는 언어에서 인정을 느끼는 것의 강력함 등이 중요하다고 강조함. 소프트웨어 설계가 인간 관계의 연습이라는 켄트 벡의 말에도 동의함. 컴파일러, 문서, 표준 라이브러리, 타사 라이브러리, 패키지 관리자, 프레임워크, 포맷터, 프로파일러 등 언어를 지원하는 모든 구성 요소들이 특히 중요함.