▲

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

 (corrode.dev)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 러스트는 기존 프로그래밍 경험과 상관없이 새로운 사고방식을 요구하는 언어로, 겸손한 태도가 가장 중요한 학습 요소임
  • 초보자는 clone()이나 unwrap 등을 사용해도 좋으며, 간단한 코드 작성과 반복을 통해 점진적으로 이해를 넓혀야 함
  • 러스트는 정확성과 디테일에 강하게 의존하며, 컴파일러의 에러 메시지를 깊이 이해하는 습관이 중요함
  • LLM이나 자동 완성에 의존하지 말고, 직접 타이핑하며 몸으로 익히고, 타입 주도 개발 방식으로 구조화된 사고를 훈련해야 함
  • 러스트를 배우는 데는 시간이 오래 걸리지만, 장기적으로는 높은 안정성과 생산성을 제공하며, 그 가치를 믿고 꾸준히 학습해야 함

Let Your Guard Down

  • 러스트는 기존 언어와는 전혀 다른 사고방식을 요구하며, 라이프타임·소유권·트레잇 시스템 등 새로운 개념들을 받아들여야 함
  • 언어에 대한 태도가 학습 성과를 결정하며, 경력이 많아도 자존심을 내려놓지 않으면 오히려 학습에 방해가 됨
  • Borrow checker를 적으로 보지 말고 동료로 인식, 컴파일러의 지시에 따라 코드 구조를 개선하는 기회로 삼아야 함
  • 러스트의 장황함은 큰 프로젝트에서 읽기 편하고 유지보수에 강한 장점으로 작용함
  • Clippy 린트를 적극 활용해 정적 분석 습관을 들이는 것이 권장됨

Baby Steps

  • 처음부터 모든 걸 완벽히 하려 하지 말고 clone(), unwrap 등을 자유롭게 사용하며 점차 개선하는 것이 효과적임
  • .and_then 같은 고급 문법보다는 기본적인 if나 match로 시작하는 것이 좋음
  • 비동기 러스트는 초반에 피해야 하며, 개념당 하나의 main.rs를 만들고 실험적으로 접근하는 것이 추천됨
  • 러스트 플레이그라운드에서 자주 실험하며 개념별로 코드를 써보는 습관이 효과적임

Be Accurate

  • 러스트는 작은 실수도 허용하지 않기 때문에 정확성이 중요하며, 사소한 오타도 미리 잡는 습관이 필요함
  • &나 mut를 자동으로 넣는 근육 기억 형성이 중요함
  • 예시로 추천된 Tsoding의 코딩 스트리밍 영상에서 정확하게 코딩하는 모습을 참고할 수 있음

Don’t Cheat

Walk the Walk

  • 읽는 것보다 직접 코딩하는 것이 진짜 학습임
  • 완벽하지 않아도 코드를 오픈소스화하고, 실제로 손을 많이 움직여야 실력이 쌓임

Don’t Go on Auto-Pilot

  • LLM에 의존하지 말고 자력으로 타이핑하는 습관을 들여야 진짜 이해에 도달함
  • 러스트 플레이그라운드에서 직접 입력하고 실험하며 개념을 익히는 것이 중요함

Build Muscle Memory

  • 자동완성에 의존하지 않고 오타를 직접 경험하며 컴파일 에러를 몸으로 익히는 과정이 중요함
  • 러스트 특유의 느낌을 익히려면 컴파일러의 메시지를 반복적으로 접해야 함

Predict The Output

  • 코드 실행 전에 컴파일 가능 여부를 예측하는 연습을 통해 직관을 강화함

Try To Solve Problems Yourself, Only Then Look Up The Solution

  • 먼저 자력으로 시도한 후 다른 사람의 코드를 참고하는 것이 진정한 학습이 됨
  • 자신의 회피 습관 (예: unsafe, clone)을 추적하여 약점을 보완하는 방향으로 학습해야 함

Break Your Code

  • 문제 해결 후 코드를 의도적으로 깨뜨려 보며, 컴파일러 반응을 학습하는 것이 효과적임

Don’t Use Other People’s Crates While Learning

  • 학습 중에는 외부 크레이트보다 직접 구현해보는 경험이 더 가치 있으며, 단 serde나 anyhow 같은 일부 예외는 허용됨

Build Good Intuitions

  • 라이프타임이나 소유권 개념은 그림을 통해 시각화하면 이해에 도움이 됨
  • Excalidraw 같은 도구로 구조를 스케치하며 학습하는 방식이 추천됨

Build On Top Of What You Already Know

  • 러스트는 기존 언어와 유사한 점도 있지만, 특히 값 전달과 제어 흐름에서의 차이를 정확히 인식해야 함

  • 언어 간 개념을 매핑해보며 학습하면 간극을 빠르게 메울 수 있음

    • 트레잇 → 인터페이스 비슷
    • Option → Maybe 모나드
    • struct → 클래스 유사 등

  • Rosetta Code에서 여러 언어와 러스트 코드 비교하기

  • 기존에 알고 있는 도메인의 코드를 러스트로 이식하며 학습하기

Don’t Guess

  • 러스트는 추측이 아닌 세부사항 중심의 언어이므로, to_string()처럼 의문이 드는 부분은 깊이 파고들어야 함
  • 컴파일 에러 메시지는 러스트만의 중요한 학습 기회이므로 무시하지 말고 천천히 음미하는 자세가 필요함

Lean on Type-Driven Development

  • 러스트는 타입 시스템 중심의 언어이며, 이를 설계의 중심에 두는 것이 중요함
  • 표현식, 반복자, 트레잇의 관계를 이해하고 타입 기반으로 프로젝트를 모델링하는 방식이 추천됨
  • 표준 라이브러리의 문서와 구현 코드를 직접 읽으며 깊이 있는 학습이 가능함

Invest Time In Finding Good Learning Resources

  • 자신의 학습 스타일에 맞는 자료를 먼저 탐색하는 것이 장기적으로 시간을 절약함
  • Toy 예제가 지루하다면 Project Euler, Advent of Code 같은 실용적인 문제 풀이가 더 도움이 됨
  • 유튜브는 오히려 오락용으로 보는 것이 좋으며, 진지한 학습은 책이나 강좌가 더 효과적임

Find A Coding Buddy

  • 더 숙련된 동료에게 그림자처럼 붙어 배우거나, 포럼·Mastodon에서 코드 리뷰를 요청하는 것이 좋음
  • 다른 사람의 러스트 코드를 설명하는 연습을 통해 개념의 내면화가 가능함
  • 자신만의 러스트 용어 사전을 만들어두고, 배운 내용을 정리·공유하는 습관을 가지는 것이 추천됨

Believe In The Long-Term Benefit

  • 러스트는 이력서 장식용 언어가 아닌, 장기적으로 즐기고 사용할 사람에게 적합한 언어임
  • 익숙해지기까지 시간이 걸리지만, 러스트는 제2일차부터 생산성이 증가하는 언어임을 믿고 꾸준히 학습할 것
  • 장기적인 코드베이스를 위해 초기에 학습과정에 투자하는 것이 개인과 조직 모두에 이득임
▲
GN⁺ 5시간전  [-]
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이었음

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

답변달기