최근 Rust를 살펴보고 있다.
새로운 언어 학습을 위한 시도로, 여러가지 글들로 접해본 Rust의 포지션은 Go와 비교되는 일이 많았다.
특히 C++의 대체자로 Go와 Rust가 꼽히는 글을 많이 접했고, 그래서 상대적으로 많은 분들이 추천하셨던 Go를 먼저 시작하게 됐었다.
그러던 중, 즐겨찾기 동기화 오류가 극심하던 엣지를 버리고, 주 사용 브라우저를 Firefox로 갈아타게 됐고, 그 과정에서 모질라 재단에서 만들고 있는 Rust를 다시금 관심을 가지게 됐다.
동시성, 병렬 프로그래밍에 큰 장점이 있다는 것은 두 언어가 비슷했으나, 꽤나 두 언어는 차이점이 명확했다.
Go가 가장 마음에 걸렸던 점은, C++과 Java등의 언어들이 가진 단점에 대한 해결책을 거의 제시하지 못했다는 점이다.
Google이 만든 언어라는 점 말곤 사실상 메리트는 없다고 느껴졌다.
이에 대한 글들도 상당히 많은 상태고. https://github.com/ksimka/go-is-not-good
Rust는 Go와 다르게, 명확한 대안 몇가지를 제시했다.
특히 와닿는 것은 가비지 컬렉션이 없다는 점과, 동시성에 대해서 Mutability로 해결하고자 했다는 점이다.
C++, Java가 겪은 동시성 문제에 대한 해결책으로 Rust또한 베스트라 말하기 어려운 대안을 제시했다. 그렇지만 적어도 어떠한 문제가 있었는지는 확실히 이해한 상태에서, 명확한 장단점이 있지만, 어떠한 판단을 근거로 대안을 마련했는지가 뚜렸한 해결책을 제시했다.
요구 사항이 모호하면 모호할수록 기술적 선택은 어떤 선택이든 별반 차이가 없다.
요구 사항이 명확하다 해도 기술 선택에 영향을 주지 않는 경우도 많은데, 이 경우 작업자 다수가 익숙한 기술 선택이 당위성을 얻는 경우가 많다.
또한 라이브러리 (=패키지, =Gem) 수도 꽤 큰 당위성을 얻는다.
필수 패키지 셋들이 충분하면 (Std계열이라 불리는) 어느정도 커버가 되긴하지만, 편의성을 개선해놓거나 선택의 폭이 넓은 게 단점일리는 없으니 납득도 간다. 실제로 대다수의 상황에서 성능의 문제라거나 사용성의 문제등의 이유로 기본 라이브러리보다는 사용자 라이브러리가 선택되는 일이 꽤 빈번하기 때문이기도 하고.
그런 의미에서 아직 Rust는 시기 상조다. http://www.modulecounts.com/ 기준 9000개를 조금 넘어선 수준인데, 이는 기능 구현에 필요한 기능의 패키지가 없을 가능성이 꽤 높다는 얘기다. 패키지가 존재한다해도 기능이 불완전 할 가능성도 꽤 높다. (.NET CORE용 패키지들의 현상태만 생각해도….)
그럼에도 나는 Rust를 선택했다. Rust가 얻고자 하는 것이 명확 했다는 것은, 학습 이후에도 얻어가는 것이 있고, 그 장점이 서버 언어로 충분한 장점을 가져다 줄 것이라 믿는다. (Rust의 단점은 장점을 확고히 하기 위함이기에 더더욱 마음에 들었다.)
이 것이 내가 Rust를 선택하게 된 이유다. 이어서 Rust로 사용기와 Rust로 만드는 프로그램에 대한 이야기를 조금 더 이어가 보도록 하겠다.