자바, C, C#, Javascript, Python 등 해봤지만
최근 언어에서 오는 한계를 느끼고 루비나 스칼라도 보고 있지만 먼가 부족.
그래서 보고 있는게 Go랑 Rust인데 어떤 멍청한 애들은
Go vs Rust 로 싸우더라. Rust는 C 대체를 목적으로 Go는 생산성을 목표로 둔거라 추구하는것이 다른데 말야.
우선 Go 는 정말 쉽더라. 유튜브에 양키가 올려놓은 30분짜리 영상 보면 그냥 끝임.
성능도 자바를 따라오는 수준이고 컴파일도 빨라서 좋음. 다음 1.7 버전에선 런타임 속도 향상 위해서
컴파일 기술 추가하는것 때문에 컴파일이 2배정도 느려질거라는데 아무튼 괴물 언어 개발자들이 모인만큼
Go는 급부상할 수 있는 언어가 될거라는 느낌이 듬. 쉽고 빠르고 게다가 뒤에 갓구글이 지원해주고 있으니...
근데 Rust 가 지금 너무 모호하다. 컴파일도 진짜 더럽게 느리고
또 Rust 의 제약 사항이 C를 대체할만큼의 효율성이 나올까 의문이 든다.
이 언어가 가진 제약은 C을 할때 포인터에 주의를 하는것과 같다고 할까?
즉 Rust 가 safe memory를 지향한다고 해도 거기에 따른 제약 사항은 결국 그 만큼의 희생도 필요하지 않은가?
C++11 을 적극 도입하는것과 다를게 무엇인가?
crates 의 유용함을 애기하지만 옵셔널적인 툴의 성격일뿐..
양키들도 Rust에 대해서 대해 고민이 되게 많은것 같더라. 모질라는 이미 차세대 브라우져에 Rust를 도입하고
있지만 다른 개발팀이나 커뮤니티에선 나랑 비슷한 고민을 하거나 회의적인 생각을 많이 함.
그러다가도 또 요즘엔 나 자신이나 다른 개발자 역시 C에 너무 익숙한 나머지 특정틀에 갇혀버린게 아닌가 생각도 함.
자바를 처음 접했을때도 포인터없이 어떻게 자유자재로 프로그래밍할 수 있을까 생각했지만
몇년 지나고 나니 지금은 프로토타입은 프로그래밍은 항상 자바나 파이썬으로 개발하니까...
컴파일 타임이 느린 건 그만큼 컴파일러가 소스코드를 검사하고 여기저기 살펴보고 최적화하는 작업을 많이 한다는 거 아니겠냐? 고 컴파일러는 그런 기능이 거의 없고 전부 다이나믹 체킹임. 계산 표현의 정적인 부분을 좋아하는 사람은 러스트같은거 쓰면 되고 동적인 부분을 좋아하는 사람이라면 고같은 언어 쓰면 되는거지 정해진 답은 없지. 근데 나는 결국 프로그래밍 활동이라는게 기계와 소통하는, 기계의 도움을 받는 활동으로 변할 거라고 생각한다. 당장 Elm만 봐도 컴파일러가 거의 코드 어시스턴트급이지. 러스트의 타입 시스템같은 정적 분석 기술이 발전하면 나중에는 이거 해줘 저거 해줘라고 부탁하면 컴파일러가 알아서 해당 부분을 변화시키고 부족한 부분을 채워넣고 더 나아가서 제안까지하게 될 거라고 생각함.
실무에선 둘다 별로 도입할 생각이 없는듯 하더라. 신기술 연구쪽의 동기들도 선배들이 그냥 몇년뒤에 살펴보자고 아직은 시기상조라고 한다고 한다.