Rust의 학습 곡선 평탄화 가이드

• 러스트는 완전히 새로운 사고방식을 요구하는 언어로, 마음가짐이 학습 속도에 큰 영향을 줌
• 컴파일러와 친해지는 것이 핵심이며, 오류 메시지를 단순히 고치는 것이 아니라 이유를 이해하는 태도가 중요함
• 초반에는 clone(), unwrap 등을 적극적으로 사용해 작게 시작하고 점진적으로 리팩토링하는 것이 좋음
• 코드를 손으로 많이 작성하며 실수와 시행착오를 통해 직관과 근육 기억을 쌓아야 함
• 러스트는 타입 시스템 중심의 개발 철학을 갖고 있어, 문서를 꼼꼼히 읽고 타입으로 모델링하는 연습이 필요함

---

Flattening Rust's Learning Curve

러스트는 배우기 까다로운 언어로 알려져 있지만, 이 글에서는 러스트를 보다 효과적으로 배우기 위한 태도와 접근 방법에 대해 저자의 경험을 바탕으로 구체적인 조언을 제시함

Let Your Guard Down

• 러스트는 기존 언어와 다른 정신 모델을 요구함
• 초보자가 고수보다 빠르게 익히는 경우도 있음 → 태도와 열린 자세가 핵심
• 빌림 검사기(borrow checker) 를 적으로 보지 말고 공동 저자로 여겨야 하며, 오류 메시지를 이해하려고 노력해야 함
• 컴파일러가 lifetime 파라미터를 요구하는 이유를 깊이 이해하려는 자세가 중요함
• 코드가 보기 싫고 복잡할수록 잘못된 설계일 수 있음, 더 나은 방법을 찾는 계기로 삼아야 함
• 러스트의 장황함(verbosity) 은 대규모 앱에 도움이 되며, 리팩토링에 유리함
• clippy 린트는 꼭 초반부터 모두 켜고 활용해야 함

Baby Steps

• 초반에는 String, clone(), unwrap 을 아낌없이 쓰고 나중에 리팩토링해도 무방함
• 복잡한 메서드 체인보다 간단한 if, match 문부터 시작
• 비동기(async) 는 첫 주에는 피하는 것이 좋음
• 작은 코드 조각을 Rust Playground에서 실험해보며 학습
• 개념 하나당 main.rs 파일 하나로 실습하고, 대부분의 코드는 버릴 생각으로 작성

Be Accurate

• 러스트는 정확함이 생존 조건
• 타이포나 작은 실수가 바로 컴파일 오류로 이어지므로 주의가 필요함
• &, mut를 자동으로 붙이는 습관을 들이면 도움이 됨
• Tsoding 같은 개발자의 스트리밍 영상은 좋은 참고 자료

Don’t Cheat

• LLM, 코드 자동 완성에 의존하면 학습이 느려짐
• 직접 손으로 타이핑하고, 이해되지 않으면 문서를 찾아보는 연습 필요
• 자동조종 상태(auto-pilot) 로 코딩하지 말 것
• 실수를 수용하고, 이를 통해 컴파일러의 작동 방식을 이해할 것
• 코드를 실행하기 전에 컴파일 가능 여부를 예측하는 연습도 추천
• 다른 사람의 코드를 읽고 분석하는 습관도 중요
• 학습 중에는 외부 Crate 사용을 자제하고, serde, anyhow 정도만 예외로 허용

Build Good Intuitions

• lifetime, ownership 개념은 시각적으로 이해하는 게 도움됨
• excalidraw 같은 도구로 데이터 흐름, 아키텍처 등을 직접 그려보는 습관 추천
• 많은 뛰어난 엔지니어와 수학자도 시각화 도구를 잘 활용함

Build On Top Of What You Already Know

• 러스트는 익숙한 개념에서도 작동 방식이 다름 (예: mut, 값 이동 등)
• 그러나 기존 언어와 비교를 통한 학습은 유용함

예시:

• Trait → Interface 와 비슷하지만 다름
• Struct → 상속 없는 클래스 느낌
• Closure → 람다와 유사
• Module → 네임스페이스
• Borrow → 단일 소유자 포인터
• Option → Maybe monad
• Enum → Algebraic data type

• Rosetta Code는 여러 언어간의 코드 비교 학습에 유용
• 익숙한 언어의 코드를 러스트로 포팅하며 학습하는 것도 효과적
• 리스트 내장 문법이나 반복문 등의 언어별 관용 표현을 러스트에서는 어떻게 표현할지 고민하는 연습도 좋음

Don’t Guess

• 러스트는 추측이 통하지 않는 언어
• "hello".to_string() 같은 코드를 왜 써야 하는지 이유를 고민해볼 것
• 오류 메시지는 매우 유익하므로, 그 안에 숨겨진 힌트를 절대 무시하지 말 것
• 특히 borrow-checker 관련 오류는 데이터 흐름을 손으로 추적하며 분석해야 함

Lean on Type-Driven Development

• 러스트는 타입 시스템 중심 언어
• 함수 시그니처, 타입 정의 등에서 많은 정보를 얻을 수 있음
• 표준 라이브러리 문서와 소스를 자주 읽을 것
• 타입 먼저 설계하고, 그에 맞는 코드 작성을 통해 더 정확하고 재사용 가능한 구조 구현 가능
• 불변성(invariant)을 타입으로 표현하면 아예 잘못된 코드가 컴파일되지 않음

Invest Time In Finding Good Learning Resources

• 러스트 학습 자료는 아직 많지 않지만, 초반에 자신에게 맞는 리소스를 찾는 것이 시간 절약에 중요함
• Rustlings 같은 학습 툴은 성향에 따라 호불호가 갈림
• Advent of Code, Project Euler 같은 문제풀이 중심 자료가 더 적합할 수 있음
• 유튜브 영상은 정보성보다는 엔터테인먼트로 활용
• 책을 사서, 오프라인으로 읽으며 직접 코드를 작성하는 방식이 가장 효과적
• 가능하다면 전문가의 교육이나 코칭을 받는 것도 장기적으로 큰 시간 절약 가능

Find A Coding Buddy

• 실력 있는 동료의 코드를 그림자처럼 따라가며 관찰하는 것도 좋음
• Rust 포럼, Mastodon 등에 코드 리뷰를 요청하거나 직접 리뷰하면서 실력 향상 가능

Explain Rust Code To Non-Rust Developers

• 러스트를 모르는 사람에게 설명해보는 것도 학습에 효과적
• 오픈소스 프로젝트의 유지되지 않는 코드에 기여하는 것도 추천
• Rust 용어를 자신의 업무 도메인 언어로 매핑한 용어집을 작성하면 좋음

Believe In The Long-Term Benefit

• 러스트는 단기 생산성보다 장기 품질을 위한 언어
• 하루아침에 고수가 되긴 어렵지만, 한 달 집중하면 많은 걸 얻을 수 있음
• 러스트는 ‘Day 2 언어’이며, 첫날은 힘들지만 지속적으로 사용하면 가치가 커짐
• 성공하려면 단순히 이력서용이 아니라, 프로그래밍 자체를 좋아해야 함

[aer0700]

예전에 학습 목적으로 예전에 c로 작성했던 코드를 rust로 재작성해본 적이 있었는데, 포인터 다루는 게 너무 괴로웠던 경험이 있네요... rc나 refcell 등의 작동이 머릿속에서 정리가 잘 안 되어서...

[q8840]

기본 문서, 노미콘 순서대로 한번만 읽고 난 뒤에 러스트에 대해 한번도 막힌적 없었는데 그렇게 학습곡선이 높나 싶습니다

[freedomzero]

오으 unwrap과 clone에 맛들이면 나중에 소유권 때문에 너무 고통스러울텐데ㅠ

[GN⁺]

Hacker News 의견

• “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이었음

• 이 댓글들을 보며 오래된 프로그래머들이 지적받았을 때 주로 보이는 태도를 깨달음, 오래 일할수록 고집이 세지기 쉬움, 컴파일러의 제안을 왜 거부하게 됐는지 각자 스스로 생각해 보면 좋겠음, 뭘 다르게 하고 싶은지, 무엇이 막고 있는지 직접 따져봐야 함