러스트 언어를 쓰면서 가장 크게 고통받는 지점은 다음과 같다.

  1. 아무런 도움도 안되는 강제 네이밍

    이게 문제라고 생각하는 이유는 다른 것이 아니다.

    수학이라 할 지라도 규칙을 풀기 위해 연상하는 대상이 다르고, 절차가 다르고, 방식이 다르고, 키가 다르다.

    나는 명시적으로 단어들을 띄워놓고 왼쪽을 더 추상적인 단계로 우측을 더 구체적인 단계로 둔다.

    그리고 이 구분이 명확해지도록 언더바를 적극 활용하며 이를 극대화 할 수 있는 것이 Visual Studio의 Intellisense였다.

    단어의 앞단어를 적고 텝을 사용하면 빠르게 완성해주는 기능을 동원해서 조금 길어도 단시간안에 글자를 완성할 수 있었다.

    그런데 rust는 그런 기능을 통해 사람의 사고를 자유롭게 확장하게 도와주지 않는다.

    메모리 관리 측면에서 고민해봤을때 전혀 관계없는 네이밍 방식까지 딴지를 놓는 최악의 언어이다.

    규칙을 지켜야 한다고?

    그 규칙이 프로그래밍에 있어 절대 규칙으로 지켜져야할 천상의 규율이라도 되나?

    코딩은 내 맘대로 할 수 있고, 그 결과를 이룩할 수 있다.

    동료들과 함께 해야하는 코딩이라면 컨벤션이 있을 수 있다.

    그런데 이건 동료랑 상관없는 내 영역에마저 딴지를 놓는게 아주 최악이다.

    다른 발전이라곤 전혀 발생할 수도 없고 인정도 안 하는 독재의 언어이다.

    미닉스나 유닉스 계얼에 제대로 된 IDE가 없으니까, OS의 영역에서 추적해야 할 메모리 관리를 언어에 떠넘기고 그 결과 찾아온 지옥이다.

    OS가 책임을 지지 않아 발생한 문제를 개인에게 돌리면서 생긴 문제이다.

    Windows는 메모리를 자체 힘으로 관리하면서, 이걸 개발자에게 그래프 등으로 실시간 수치를 제공해주고 추적에 대해 많은 고민이 되어있다.

    그래서 툴만 사용하면 메모리 누수를 놓칠리가 없고, 발생해도 금방 찾는다.

    OS에서 이런 문제를 책임지고 추적할 수 있도록 자체적인 Visual C++ 이라는 표준을 갖춰둔 Windows에서의 C++ 코딩이 너무 그립다.

  2. 객체지향이 아닌 러스트

    거대한 프로젝트를 진행하기 위해 작업을 나누어야 한다면, 명시적으로 책임을 주어야 할 경우가 생긴다.

    하지만 공식적으로 객체지향이 아니고, 객체를 만들 수 없는 러스트는 최악의 선택이라 할 수 있다.

    그러니까, 조금 더 C 스타일에 가까운 파이선 같은 언어이다.

    파이선도 규모있는 프로그래밍이 가능하지만, 인덴트 한방에 박살나는 약점이 있는 것 처럼

    러스트는 사람들이 눈치껏 자기 범위를 챙겨야 한다.