구글이 Go라는 언어를 만들면서, 시스템 프로그래밍에 사용할 수 있고, C/C++ 성능에 비견할 만한 언어라고 떠들어 댈 때, 애플이 Swift 언어로 세상을 놀래킬 때, 혹시나... 하는 기대가 없었던 것도 아니다. 근데... 막상 뚜껑을 열어보니... 아직 멀었다. 자바스러운 아키텍쳐에 파이선(Python)스러운 간결함을 약간 섞고, 신택스 좀 바꾸는 수준이다. D스럽다고나 할까... 하기사 뭐, 자바(Java)로도 온갖 지랄들을 다 떨 수 있는데, Swift나 Go로 못할 것도 없지... 라고 생각하고는, 결국 코딩 할 때는 C/C++를 쓸 수 밖에 없다. 일단 시스템 프로그래밍에 맞지 않기 때문이다.


시스템 개발자들은 본능적으로 Swift/Go가 C/C++를 대체할 물건이 아님을 안다. 간단한 이유다. 메모리 관리를 그렇게 하면 안되기 때문이다. 가비지 콜렉션(Garbage Collection)은 프로그래밍에 서툰 어린이들을 위한 것이지 성숙한 성인을 위한게 아니기 때문이다. 쌍코피 흘리면서까지 C/C++을 지키며 미개인/원시인 취급 받을 때에도 자존심 하나로 버틴 이유는, 극단적인 상황에서 메모리 관리에 C/C++에 대응할 만한 대안이 없었기 때문이다.


근런데 달라졌다. 걸출한 Rust라는 물건이 나왔기 때문이다. Rust는 진정한 시스템 개발자를 위한 언어인 것으로 보인다.


Rust에서는 메모리 관리는 필요에 따라 가비지 콜렉터에게 위임할 수도 있고, 내가 직접 관리할 수도 있다. 뭐.. 그게 다야? 그런 특성은 Objective-C에도 있었고, 사실 C#에도 일부 있잖아...라고 생각할 수도 있겠지만, 그정도 수준에 머물렀다면, Rust에 주목하지 않았을 것이다.


노련한 개발자는 자기가 만든 프로그램의 메모리 정도는 관리할 줄 알아야 한다. 특히 그게 성능 크리티컬한 부분이라면, 자존심을 걸고 그렇게 해야 한다. 하지만 캐쥬얼하게 간단히 쓰는 변수들까지 모두 관리하자면 피곤하니까, 그럴 때는 가비지 콜렉터에 넘겨주는 여유 정도는 부릴 수 있는 것이다.



출처: http://blog.daum.net/_blog/BlogTypeView.do?blogid=0ISrw&articleno=7864764&categoryId=0



필자는 GO언어로 가고 있다고 한다.

아마 아직 러스트가 그닥 성숙단계에 와있지는 않기 때문이겠지.