“A Discipline of Programming”을 읽는 느낌임, Dijkstra의 도덕적인 설명 방법이 옛날에는 꼭 필요했던 이유는 다들 프로그래밍 개념 자체를 이해하지 못했기 때문임, Rust의 소유권 설명은 대개 너무 장황함, 핵심 개념은 대부분 있긴 하지만 예시 아래에 감춰져 있음, Rust에서 각 데이터 객체는 정확히 한 명의 소유자를 가짐, 이 소유권은 항상 한 명만 유지하도록 넘길 수 있음, 여러 명의 소유자가 필요하다면, 진짜 소유자는 참조 카운팅 셀이어야 함, 이 셀은 복제 가능함, 소유자가 사라지면 그가 소유한 것들도 사라짐, 참조(ref)를 사용해 데이터 객체에 대한 접근을 일시적으로 빌릴 수 있음, 소유와 참조는 명확히 다름, 참조는 전달 및 저장이 가능하지만 그 객체보다 오래 살아남을 수 없음, 그렇지 않으면 “댕글링 포인터” 에러가 됨, 이 규칙들은 컴파일 타임에 빌림 검사기로 엄격히 강제됨, 이게 Rust의 소유권 모델임, 이해하면 세부사항은 결국 이 규칙들에 귀결됨
- 나만 그런지는 모르겠지만 이런 식의 개념 설명은 따라가기 힘듦, 캡슐화도 마찬가지였음, 그냥 정보를 숨긴다는데 구체적으로 어떻게/왜 그런지 파고들지 않음, 예를 들어 Rust에서의 소유자가 정확히 누구인지 이해가 안됨, 스택 프레임이 소유자인가? LIFO 구조상 소유권을 왜 callee에게 넘기는지, callee 스택이 먼저 사라지니 위험이 없는 것 아닌가 생각됨, 최적화를 위해서라면 객체를 더 빨리 정리할 수 있는 건가? 소유자가 스택 프레임이 아니라면 누구에 해당하는지도 모르겠음, 가변 참조를 왜 1번만 줄 수 있는지도 헷갈림, 싱글 쓰레드 환경이면 어차피 한 함수가 끝나기 전엔 다른 함수가 시작하지 않으니 둘 다 가변 참조를 받아도 무방해 보임, 멀티스레드 환경에서만 문제 생기면 그때 에러 내도 괜찮지 않나 싶음, 이런 의문 때문에 Rust를 공부하려다 자꾸 포기하게 됨
- 이건 소유권을 설명한 게 아니라 동기를 부여하는 설명임, 가장 어렵고 핵심은 함수 시그니처에서 라이프타임이 복잡하게 꼬인 경우를 읽는 방법과 그런 함수 호출 시 발생하는 컴파일러 오류를 이해하고 수정하는 방법임
- 이미 이 개념들을 아는 사람에게 옳고 완벽하게 보이는 요약을 만드는 일은, 처음 배우는 사람에게 설명하는 일보다 훨씬 쉬움, 만약 이런 식으로 설명하면 call-by-sharing만 쓰던 사람이 바로 이해할 수 있을까? 그럴 것 같지 않음
- Rust를 모르는 사람이 이 요약만 읽고 나면 Rust에 대해 아무것도 모를 것임, “이 언어는 마치 컴파일러에 블랙매직이라도 있는 것 같다”는 생각만 들 것임
- 소유권과 빌림 개념 자체는 쉽게 이해할 수 있음, Rust가 정말 배우기 어려운 이유는 함수 시그니처와 실제 사용 코드가 참조가 객체보다 오래가지 않음을 서로 증명해야 하기 때문임, 참고로, 참조된 객체를 타입에 저장하지 않는 것이 증명을 덜 복잡하게 만들기 때문에 더 나은 선택임
- 60년대 사람들이 어셈블리 수준에서 시스템/애플리케이션 상태를 어떻게 다뤘는지에 대한 글을 오래 찾고 있었음, Sutherland의 Sketchpad 논문에 데이터 구조 관련 상세 설명이 많다고 들었지만 2-3장만 읽어봄
- 이 설명이 내게는 의미 있게 다가오지 않음, 소유권과 빌림을 명확히 정의하지 않음, 둘 다 금융 자산 관리에 빗댄 은유에 기반한 단어처럼 보임, Rust에 익숙하지 않지만 이런 단어 선택 자체가 개념을 이해하기 어렵게 만드는 것 같음, 은유는 종종 양날의 검임, 좀 더 직접적인 메모리 관련 용어로 설명하는 것이 도움이 될 것 같음
- 모델 설명에서 중요한 배타적/공유(또는 가변/불변) 빌림 차이를 완전 빼놓았음, Rust는 이런 빌림을 어떻게 허용할지에 대해 많은 선택을 했고 이건 직관적이지 않음, 예를 들어 no aliasing 규칙은 직관에서 비롯된 게 아니라 함수 최적화 목적에서 생긴 것임, 빌림에서 가장 복잡한 건 라이프타임 elision 규칙 때문에 컴파일러 오류 메시지가 진짜 원인과 엉뚱한 곳을 가리키는 경우임, 이 elision 규칙들은 직관적이지 않고 단순화하려고 도입된 선택이었음
- Brown University가 러스트북을 개정한 버전이 빌림 검사기 설명을 정말 잘해줌
- 설명이 완전하지 않은 것 같음, 예를 들어 빌린 쪽이 사라지면 어떻게 되는지에 대한 내용이 없음
- “진짜 소유자는 참조 카운팅 셀이어야 한다”라고 했는데 그게 뭔지 아는 사람만 이해할 수 있게 설명한 것 같음
- 나만의 빌림 검사기를 구현해 봐야 비로소 빌림 검사기가 이해가 됨
- 두 번째 섹션의 두 번째 항목은 심각하게 과장임, 실제로 러스트가 컴파일하지 않지만 안전한 코드를 쓸 수 있는 수많은 경우가 존재함, 컴파일러가 무엇을 증명할 수 있는지 한계를 명확히 하기 위해 이런 복잡성이 생겨났음
Rust의 소유권 모델, 라이프타임, enum 및 패턴 매칭이 처음 접할 때에는 굉장히 부담스러웠음, 첫 번째로 도전했을 때는 너무 빨리 압도당했고 두 번째 도전에서는 책의 모든 줄을 다 읽으려 했더니 인내심이 바닥남, 그 와중에 Rust가 프로그래밍과 소프트웨어 설계에 대해 더 깊은 통찰을 주는 언어란 걸 깨달음, 세 번째 시도에서 비로소 내가 전에 썼던 작은 프로그램과 스크립트를 Rust 스타일로 다시 쓰면서 배우기 시작했고, 그 과정에서 러스트스러운 에러 핸들링, 타입을 적극 활용한 데이터 표현, 패턴 매칭 등도 익혀감, 이런 경험 끝에 러스트를 배운 것이 내 프로그래머 인생 최고의 결정 중 하나임을 확신함, 타입, 구조체, enum을 미리 정의하고, 불변 데이터와 패턴 매칭에 기반해 함수 작성하는 방식이 이제는 다른 언어에서도 자연스럽게 적용함
- 비슷한 경험을 했음, 러스트를 세 번째로 배울 때 제대로 감이 오기 시작했고, 몇몇 프로그램을 효과적으로 작성할 수 있게 됨, 오랜 프로그래밍 경력이 있음에도 반복 학습이 필요한 경우가 있음, 예전에 JVM의 의존성 주입 프레임워크인 Dagger를 이해할 때도 정확히 3번의 학습 시도가 필요했음, 어쩌면 복잡한 걸 배울 때 나한테 공통적으로 나타나는 패턴일 수 있음
- C++ 개발자들이 Rust를 처음 접할 때 자주 보는 현상인데, C++ 관념으로 하면 “빌림 검사기”랑 계속 싸우게 됨, 러스트 관습을 제대로 익히면 그 관습들을 다시 C++에도 가져와 더 견고한 코드를 쓰게 됨, 비록 C++에는 빌림 검사기가 없어도 말임
“컴파일 전에 코드 전체를 꼼꼼히 읽고 오타를 수정하면 더 나은 시간을 가질 수 있음”이라는 조언은 낯설게 느껴짐, Rust 컴파일러가 아주 친절한 오류 메시지로 유명한데, 굳이 내가 오타 찾으려고 코드 붙들고 있을 이유가 있나 싶음, 컴퓨터가 내 오타를 잡아주기를 원함
- cargo fix는 일부 문제를 자동으로 수정해 주지만 모든 문제를 해결하진 못함
“저항하지 말라”, “배우기 위해선 오만은 버려라”, “포기 선언 필요”, “저항은 쓸모없다, 빨리 받아들이지 않으면 고생만 길어질 뿐”, “알고 있는 걸 잊어라” 등의 조언이 있어, 이걸 보니 오웰의 텔레스크린 OS가 Rust로 짜였겠다 싶음
- 이 말에 동의함, 내가 러스트를 배울 때 좌절한 가장 큰 실수는 오브젝트 지향 패러다임으로 억지로 Rust를 다루려 한 것임, 그냥 Rust가 원하는 대로 해보자고 받아들이니 바로 잘 풀렸음
Rust는 초심자에게 꽤 큰 허들이 있음, 다른 언어와 많이 다름 - 의도적이지만 그만큼 진입장벽임, 문법이 복잡하고 매우 간결해서 마치 팔꿈치로 키보드를 친 것처럼 보임, 문자 하나가 의미를 완전히 바꿀 수 있고 중첩이 심함, 많은 기능들이 이론적 배경 없이는 이해하기 어려워서 복잡성은 훨씬 커짐, 타입 시스템과 빌림 메커니즘이 대표적임, 일반적인 Python이나 JavaScript 사용자에겐 거의 외계어임, 실질적으로 석사급 CS 배경이 없는 프로그래머가 태반인 시대라서 Rust는 적합하지 않은 것 같음, 거기다 매크로는 더더욱 복잡하게 만들고 있음, 정의 내용을 알지 못하면 코드가 무슨 뜻인지 이해가 힘듦, 최근엔 LLM이 이런 장벽을 낮춰 줄 수 있다는 점에서 기대함, 아직 Rust를 배울 필요성까지는 못 느끼지만 LLM 덕분에 언젠가는 다시 시도해볼 의향이 있음, 그만큼 Rust는 독특하게 배우기 어려운 언어임
- Rust를 배우면서 가장 곤란했던 점이 바로 매크로 때문임, 내가 사용한 자료들이 설명 없이 매크로를 초반에 도입해 혼란을 줬음
어떤 상황에서도 Rust보다는 더 나은 선택지가 있을 것 같음, 그래도 열린 마음으로 있음, 언젠가 Rust가 충분히 흔해지면 그때 의미가 생길 수 있음
- 거의 20년 전부터 러스트가 처음 설계된 목적 그대로라면 브라우저를 처음부터 새로 만드는 데는 완벽한 언어임, 지금은 이 영역에서 이미 러스트가 지배적임, 그리고 언어 창시자의 “unix”가 세계를 평정했고 누군가 만든 Ladybird 따위로 대체되는 일은 없었음
어떤 언어가 사람들이 애 써가며 배워야 한다고 설득하는 글까지 필요하다면 그게 언어 설계 자체에 문제가 있는 게 아닐까 의심됨, (Rust를 배우지는 않았으니 너무 심각하게 받아들이진 말라는 뜻임)
- 네 댓글을 “어려운 건 할 가치가 없다”로밖에 읽을 수 없겠음, 모든 것에는 장단점이 있는데 단점 존재 자체가 시도조차 할 가치가 없다는 뜻인지 의문임, 하프 연주도 어렵다고 누군가 열정적으로 글을 썼다면 그럼 하프 연주는 형편없는 취미인가?
- 시니어 개발자가 되면 그때서야 Rust가 중요하게 여기는 교훈을 곁눈질해봤을 수도 있지만 제대로 체감하지는 못한 경우가 많음, 많은 사람이 “이미 가비지 컬렉션 있는 언어 쓰는데 Rust가 뭘 가르쳐주겠어”라고 생각함, 실제로 가변성과 공유 참조가 얽히면 엄청난 혼란이 생기고, 그래서 불변 객체를 많이 도입하게 됨, 불변 객체를 갖게 되면 다시금 그 객체를 편하게 변형할 수 있는 방법을 고민하게 되고, 오히려 가변 객체보다 사용성이 떨어질 수 있음, “이 객체는 변형 가능한 시점과 불변 시점이 따로 있다”를 표현하려다 보니 결국 빌림 검사기의 필요성이 생김, 빌림 검사기가 도입되면 “그러면 왜 여전히 가비지 컬렉션이 필요하지?”란 물음이 남음, 단지 객체의 라이프타임을 명확히 이해하기 귀찮아서 가비지 컬렉션을 쓰게 됨, Rust는 이런 근본적인 고민을 직접 체험하게 해 줌
- Rust의 디자인 결정은 이해하기 어려울 때가 많음, Mojo도 빌림 검사기가 있지만 Rust보다 훨씬 배우기 쉬운 이유는 몇 가지 선택에 있음, 첫 번째로 값 의미론이 있음, Rust는 초심자 때엔 늘 clone()을 쓰라고 하는데, 보통 정적 언어들(C, C++, Go 등)에서는 평소에 값 의미론이 기본임, 두 번째로 Mojo의 라이프타임은 스코프에 따라 값이 사용 가능한지 여부가 아니라 삭제 시점을 정해주는 것임, 참조가 남아 있으면 라이프타임이 연장되고, 사용이 끝나면 바로 삭제됨, 그래서 Mojo에선 “값이 오래 살지 않는다” 같은 에러는 볼 필요가 없음, 이 두 가지 디자인 선택만으로도 부담이 많이 줄어듦
- 초보자에겐 어떤 언어든 배우기 어렵기 때문에 딱히 Rust만 특별하다 할 수는 없음, 프로그래밍은 원래 학습 곡선이 있음
- 이런 글이 있다는 건 언어보다 저자에 대해 더 많은 걸 말해준다고 봄, 저자 비판은 아니고, 열정을 이렇게 공유하는 게 멋지다고 생각함
- 이 글은 Rust가 어떤 문제를 해결하는지보다는 학습 곡선 얘기만 하는 듯함, 두 가지 모두를 균형 있게 설명해야 실제로 도전할 가치가 있는지 결론 내릴 수 있음
- Rust에 대한 설계 논쟁은 얼마든지 가능하지만 이런 글이 필요하다는 사실 자체로 Rust 언어 자체를 평가하긴 어려움, 오히려 Python이 이런 글이 더 필요한 언어라 생각함, 점점 비엔지니어링 배경의 프로그래머가 늘어나다 보니, 파이썬은 역설적으로 아무나 쓸 수 있고 Rust는 아무나 못 쓰는 언어임, 누군가에게 Rust는 C, Zig 같은 언어와 비교해서 훵씬 배우기 쉬운 언어임, 파이썬도 사랑하지만 근본적으로 끔찍한 언어임을 인지함, LLM 시대에도 사람들이 최적화된 파이썬을 써야한다는 걸 별로 모름, 우리 AI 친구들도 지시하지 않으면 비효율적인 파이썬만 계속 생성할 것임
- “그게 언어 설계 문제 아닐까?”란 물음에는 “왜?”라는 반문이 나옴
- Rust를 배운 입장에서 말하자면 주로 Python만 쓴다 하더라도 Rust엔 언어적 결점이 있다고 느껴본 적 없음, 오히려 아주 엄격한 언어라서 자꾸만 Rust스럽지 않게 하려 들면 고생만 늘어남, Rust 스타일대로 하면 점점 더 복잡해질수록 오히려 큰 도움이 됨, 다른 언어에선 오류가 실행 중에 하나씩 발견되지만, Rust에선 컴파일 시점에 거의 다 잡아줌, 물론 논리적 오류는 막지 못하지만 강력한 테스트 통합 덕분에 대응 가능함, 단점도 있지만 Rust는 꼭 한번 배울 가치가 있음, Rust가 오류를 줄이기 위해 택한 방식은 다른 언어의 좋은 개발 습관으로도 활용할 수 있음
- Rust가 너무 복잡해서, LLM이 올바른 Rust 코드를 단번에 만들어내기 어려운 게 사실임, 그래도 JavaScript나 다른 약타입/동적 언어의 여러 문제보다는 그 편이 훨씬 낫다고 생각함
- 나는 Rust를 배웠고 네 얘기에 공감함, Rust는 진짜 복잡하고 “위원회 설계” 언어임, 멋진 툴링이 있지만, 그래도 C++보다는 덜 복잡하지만 결코 쉽게 배울 언어는 아님
- 이런 글의 문제는 본질에 접근하지 못한다는 것임, Rust는 아예 작성 자체를 허락하지 않는 프로그램들이 있음, 충분한 이유가 있지만, 이건 거의 모든 사람이 써온 언어들과 본질적으로 다름, 분명 Rust로 못 쓰는 프로그램이 있기 때문에 그런 걸 받아들여야 함, 아니면 Rust에 적합하지 않음
Rust를 배울 때 흔히 하지 않는 접근 중 하나는 언어의 일부분만 먼저 익혀보는 것임, 예를 들어 내 러스트 입문서에서는 라이프타임을 아예 가르치지 않음, 라이프타임 없는 함수만으로도 제대로 동작하는 프로그램을 충분히 짤 수 있음, 매크로도 마찬가지로 쉽진 않지만 어쨌든 서브셋을 먼저 배워야 함, 그리고 처음부터 copy()나 clone()에만 의존하기보단 빌림 개념부터 먼저 익히는 것이 더 옳은 접근이라고 생각함, 빌림은 언어의 핵심임
Rust를 배울 유일한 방법은 연봉 30만 달러 이상 주는 일자리가 많이 생기는 것뿐임, 앞으로 Rust가 quant 쪽에서 C++을 대체할 잠재력도 있다고 생각함, 하지만 이미 OCaml이 있고, 만약 극도로 어렵고 복잡한 언어를 배워야 한다면 일단 돈이 보여야 할 듯함, 지금까지 최고 연봉 직업은 Python이었음
이 댓글들을 보며 오래된 프로그래머들이 지적받았을 때 주로 보이는 태도를 깨달음, 오래 일할수록 고집이 세지기 쉬움, 컴파일러의 제안을 왜 거부하게 됐는지 각자 스스로 생각해 보면 좋겠음, 뭘 다르게 하고 싶은지, 무엇이 막고 있는지 직접 따져봐야 함

답변달기