그냥 취미로 하는 거여서, 그냥 이런 사람도 있구나 하고 넘어가주셈.


1. 어쩌다 하게 됐냐


현업이 아니니까 특정 언어/프레임워크 깊이 팔 필요가 없어서, 이것저것 건드려보고 직접 만들어보려다 하게 됐음.

현업으로 뛰어야 했으면 나도 당연히 java, python이나 c#같은거만 팠을것임.

처음 배운 이유는 vulkan 건드릴 일 있었는데, 당시엔 튜토리얼 있는 언어가 c/c++이랑 rust뿐이어서 rust 찍먹하다가 시작한거였음. 거창한 이유는 없음.

글고 rust 배우기 전에 r->python->julia->go 순으로 배웠는데, 이러다 보니 신택스나 라이브러리 관리 등이 c/c++보다 rust가 더 친숙해서 하게 된 것도 없잖아 있음.


2. 찍먹한 건 그렇다치고 왜 아직도 쓰고 있냐


밸런스가 적당히 좋음.

표준 라이브러리 안에서 웬만한 거 직접 구현 안 해도 만들 수 있고

cargo 있으니까 라이브러리 관리도 쉽고 문서화도 대체로 잘 되어 있음.

글고 라이브러리도 python/java/c/c++/c# 같은 것들에 비해서 없는 편이지 이정도면 마이너 중에선 꽤 생태계 큰 편이라고 느낌. 저수준에서 고수준 두루 걸쳐서 라이브러리들 적당히 있는 편이었음.

그래서 비교적 저수준 언어임에도 생각보다 간단하게 짤 수 있는 경우가 많았음.


문법적으로나 신택스적으로도 잘 설계되어 있다고 느끼긴 했는데,

그건 사실 새로 나오는 언어들 보면 대체로 다 그런 편이어서, rust만의 특징이라기보다는 프로그래밍 언어라는 분야 자체가 발전하는 중이라고 생각함.

어쨌든 이런 추세에 비추어 봐도 일단 평균 이상은 되고, 만족하고 사용할 정도는 확실히 된다고 느낌.

 

3. 그럼 어떤 경우에 쓰냐


나는 wasm만들때나 gpu건드릴 때, 계산 최적화 할 때, 단일 실행파일 만들 때 정도에 썼음.

wasm이랑 gpgpu같은 건 어차피 c/c++아니면 rust가 자료가 대부분이어서 딱히 대안이 없었고,

계산 최적화는 gc 오버헤드 없고 unsafe에서 bounds check 풀 수 있어서 그걸로라도 성능 좀 높여보겠다고 써 봤음.

그럴거면 그냥 c로 짜면 되긴 하지만, c에서 직접 메모리 관리하는 것보단 unsafe에서 필요한 것만 골라쓰는 게 더 편하다고 느낌. 그냥 개인 선호도의 영역으로 보면 될 듯.

그 밖에는 굳이 rust 쓸 필요 없어서 웬만하면 셸스크립트나 python/julia 쓰긴 하는데, 자주 써야 하는거면 그냥 rust로 짤 때도 있음.


4. 그래서 rust가 꼭 배워야 되는 언어냐


그렇진 않다고 느낌.

그래도 나름 위에서 말한 거 말고도 js나 dart도 다뤄보고, c도 ffi때문에 어느 정도 파보기도 했고 언어 경험이 적은 편은 아니라고 생각하는데,

경험상 언어 자체의 특성상 오는 우위 같은 건 애초에 유의미할 정도가 아니었음.

어차피 무슨 언어를 쓰든 하는 거 보면 비슷한 거를 비슷한 거 써서 하고 있었음.

나한테 유의미했던 건 신택스의 개인적 선호도, repl 환경이 있냐 없냐, 배포용 실행파일 만들 수 있냐 정도였고,

압도적으로 난이도 차이를 만드는 건 언어 자체보다도 교육자료 양/라이브러리 양/커뮤니티 크기 정도였음.


성능 면에서도 단순 계산 문제면 사실 gc 오버헤드 있다고 해서 그렇게 문제되지도 않았음.

가장 문제되는 건 알고리즘/자료구조/캐시 메모리 사용/멀티스레딩 락 같은 문제들이고, 이것들은 대개 수 배~수십배 정도의 속도차를 내는데, 그에 비해 gc 오버헤드 같은 건 그리 크지 않았음.

내가 julia를 자주 써서 julia랑 rust랑 구현 최대한 동일하게 해서 비교해볼 때가 좀 있었는데, 대개 1.1~1.2배 정도밖에 차이가 안 나는 경우가 많았음. 최적화도 @inbounds랑 @simd 매크로 같은 거 쓰면 julia에서도 할 수 있었고.

굳이 julia뿐만 아니라 컴파일 언어면 대개 비슷한 상황일 거임. gc에서 오는 오버헤드가 요새 그리 크지 않고 latency정도만 감안해주면 된다고 생각함.


요약하자면 언어는 준수한 편이긴 한데, 이미 프로젝트에서 쓰고 있는 언어가 있거나 현업에서 강세인 언어가 있다면 그걸 포기하고 굳이 넘어올 이유는 없음. 그리고 이는 굳이 rust뿐만 아니라 모든 언어에 해당된다고 생각함.


5. 그러면 기존 프로젝트를 rust로 바꾸거나 새로운 프로젝트로 굳이 rust를 쓰는 경우들은 이유가 뭐냐


내 생각엔 대체로 보안 문제때문에 바꾸는 것 같음.

azure CTO 발언했던 것도 걔네는 클라우드 서비스 제공하는 데니까 보안이 중요한 곳이어서 말이 나왔던 것 같고, 리눅스 커널도 마찬가지로 보안 문제 생각 안 할수가 없음.

그리고 프로젝트들도 보면 ruffle이라고 rust로 플래시 플레이어를 에뮬 개발하는 프로젝트가 있는데, 애초에 플래시가 보안 문제로 중지된 만큼 여기서도 rust를 쓰는 게 이상하지 않음.

이것들 말고도 기존 프로젝트를 교체하는 거면 웬만하면 보안 문제일 거라고 생각이 되고, 만약 그렇지 않고 신규 프로젝트인데 보안이 크게 문제가 되지 않는 거였으면 단순히 선호도의 문제로 rust를 쓰지 않았을까 생각이 됨.


6. 사족을 붙이자면 언어에 대해서 관심을 가지는 건 좋긴 한데, 그렇다고 너무 매몰되진 않았으면 좋겠음.

가끔 보면 rust 안 배우면 나중에 도태되지 않을까 하는 걱정이나, 아니면 지금 배워두면 나중에 떡상하지 않을까 하는 기대가 있는 사람들도 있는 것 같은데

언어가 무슨 주식도 아니고 안 배웠다고 손해보거나 배웠다고 떡상하거나 그런 건 없음. 다 자기 하기 나름임.

당장 취직해야 해서 관련 공부만 하기도 벅차거나, 아니면 업무량이 많아서 배울 시간이 없다면 어쩔 수 없겠지만

그런 게 아니라면 언어는 필요할 때 시작해도 충분히 배울 수 있고 다들 잘 할거임.

글고 배울 때도 기왕이면 벤치마크 같은거 보면서 성능비교할려고 하지 말고 내부적으로 구현이 어떻게 되어있는지,

예를 들어서 메모리 관리를 컴파일러가 하는지/manual하게 하는지/reference counting하는지, indexing할 때 bounds check가 되어있는지 아닌지 이런 것들부터 공부하는게 좋음.

이런 거 모르고 하다보면 코드 이상하게 짜거나, 벤치마크 이상하게 된 것도 모르고 지나가는 경우들이 생김.


글고 어차피 결국 남는건 cs/알고리즘/자료구조랑 자기분야 지식밖에 없음.

언어 배우는 건 하고 싶어서 하는 거면 괜찮은데, 실력 올리고 싶어서 그런 거라면 그 시간에 다른 거 하는 게 맞음.

많이 고민하거나 부담 느낄만한 가치가 없으니 그냥 여유있게 하십셔.