# 고언어 몇 년 간의 사용 소감
TIP
구 블로그에 남겨둔 기록을 옮겨왔다.
# 서두
고언어를 처음 알게 된건 아마도 나프다 방송을 통해서 였던것 같다. 1.4 버전이었던걸로 기억된다. 수년간 개인적인 라이브러리, 소켓서버, 웹서버등을 개발하고 사용했으니 나름 활용해보았다고 생각한다.
첫인상은 c/java 계열과는 약간은 다른 형태의 문법때문에 코드가 잘 읽히지 않아서 썩 좋지는 않았다. 그래서 책 한권 사두고 몇달 묵히다가 연습삼아 개인 라이브러리 작성을 한번 해보니 그때부터 고언어를 대하는 태도가 달라지기 시작했다.
장점을 먼저 읊어보면...
# 언어의 간단함
유닉스와 C언어의 대부들(켄 톰슨, 롭 파이크? 사실 난 잘 모름 ㅋ)이 언어 설계에 참여했다는게 딱 와닿는다. 일각에서 C 2.0으로 농담삼아 부른다던데 정말 그렇다. C언어에서 아쉬웠던, 가려웠던 부분들을 많이 긁어(?)주었고 요즘 세대 언어들의 트렌드도 많이 반영되어서 (익명함수, 다중 리턴, 클로져 등등...) 투박하다는 느낌만은 아니다. 일단 C언어처럼 기본 언어 스펙 자체가 간결하여 외워야할 것들이 굉장히 적다. 자바가 언어적 발전이 더딘 탓에 guava, rx등 언어 자체의 패러다임을 바꿔버리는 프레임워크들이 나오는 판에, 고언어는 프레임워크 없이 기본 라이브러리만으로 개발하는 경우가 허다하다. 언어가 간단하면서도 할 수 있는게 많다는 반증이지 않을까.
# 생산성, 코성비(?)
생산성이 좋다는게 무조건 코드량이 적다는 것은 아니다. 예제 프로그램이 아니고서야 필수로 써야할 멀티스레드나 동기화처리같은 부분이 언어 자체에 녹아있어서 굉장히 편하다. 파이썬이나 자바에서는 스레드 하나 생성하려면 (세세한 문법이 기억나지 않아서) 예제코드라도 들춰봐야 할텐데, 그런 부분이 정말 간편하다. C언어 스레드는 언급할 필요가. 사실 스레드가 아닌 고루틴이라고 불린다. 이름도 매력적이고, 그 내부를 알면 더욱 매력적이다. 이건 심오한 내용이므로 별도로 다루어보기로 하고. 매우 경량 스레드의 개념인데, 고루틴 수십만개를 만들어도 동작이 가능하다. 다른 언어에서는 스레드 수천개 이상은 현실적으로 힘든데 말이다. 그 외에 락이나 스레드간 통신을 위한 채널변수 등... 이건 정말 장점중의 장점이다. 그 외에 리소스 해제를 위한 defer도 다른 언어에 비해 훨씬 편하다. 파이썬에서는 with, 자바에서 try with resource와 유사한데, 다른 언어들은 리소스 할당구문 자체에 키워드를 달아야 하지만, 고언어에서는 할당 직후에 defer 구문을 사용해서 유사하게 리소스 관리가 가능하다. 굳이 비유해보자면 "이거 쓰고나서 해제할건데, 디비연결 하나 생성할게"와 "디비연결 하나 생성할게, 아 그런데 쓰고나서 해제할거야" 정도의 차이랄까. 큰 차이는 아니지만 후자의 방식이 좀 더 매끄럽다. 그게 바로 고언어의 방식이다.
# 동기식 API, 성능은 비동기식
고언어의 매우 중요한 특징이라고 생각한다. 기본 라이브러리의 API들은 모두 동기식 API 형태이다. 일부 포럼들에서도 왜 고언어는 성능좋은 비동기 API를 만들지 않았냐는 질문이 보이던데, 이는 고언어의 동작 원리를 이해하지 않았기 때문이다. 물론 RxGo등을 활용하면 비동기 API를 사용할 수 있다. 하지만 고언어의 고루틴들은 내부적으로는 비동기 형태로 동작되기 때문에 굳이 비동기 형태로 제공할 필요가 없다. 매우 흥미로운 부분인데, 최근 언어들에서 유행하는 async/await 키워드, 또는 코루틴 방식과도 매우 유사하다. 인간의 사고방식이 동기식 API 처럼 이루어지기 때문에, 결국은 비동기 API도 async/await 같은 방식을 통해서 동기식 형태를 제공하려는 추세가 보인다. 사실 비동기 API가 성능이 좋다는 말이 엄밀히 따지자면 틀린 말이다. 동일한 양의 I/O를 처리하기 위해 소모되는 컴퓨팅 파워가 동기식 API에 비해 현저히 적다라고 표현하는게 더 정확하겠다. 이것도 다른 글에서 다루어 보자.
# 크로스 플랫폼 빌드와 고성능 잠재성
대부분의 코드는 수정 없이 윈도우 리눅스를 가리지 않고 빌드가 가능하다. OS 특화 기능등에서는 약간의 구문 추가나 파일명 구분으로 분기처리하면 된다. 자바도 멀티플랫폼이 된다라고 얘기할 수 있겠지만, 차이점이라면 자바는 플랫폼 구분없이 컴파일된 바이트코드를 jvm이 구동하는 방식이고, 고언어는 플랫폼에 따라 빌드가 되어서 vm없이 바로 커널 위에서 동작하기 때문에 구조적으로 성능향상 가능성이 높다. 이견은 있겠지만 1.8버전 고언어 정도면 자바와 성능이 유사한 것으로 조사된다(어떤건 자바가 빠르고 어떤건 고언어가 빠르고). 자바 jvm이 성숙해져서 매우 성능 최적화가 된 이유도 있겠고, 아직 고 컴파일러가 성숙하지 못해서인 이유도 있다. 고언어가 몇년 후에는 더 우위에 있지 않을까 예상한다. 왜냐하면 이미 구조적으로 vm 유무가 다르기 때문이다. 인터프리터와 컴파일 언어가 구조적으로 성능 차이가 있을 수 밖에 없듯이 말이다. 하지만 아직은 컴파일러가 성숙하지 못했기 때문에 고성능 잠재성이라고 "굳이" 붙여두었다.
장점만 있는 것은 아니다. 단점도 말해보자면...
# 애매한 가비지 컬렉터
GC 때문에 고언어가 약간 애매한 위치가 되어버렸다. GC의 존재로 인해 실시간 처리가 필요한 분야에서 고언어를 사용하기가 애매해졌다. 아주 짧은 시간이라고는 하지만 "Stop the world"는 GC에서 원천적으로 없을 수는 없는 존재이고, 나노초가 민감한 분야에서는 매우 치명적인 단점이 된다. 물론 버퍼풀을 엄청나게 잘 사용하면 메모리 할당/해제를 C언어처럼 다룰 수 있고 GC의 역할을 최소화 할 수는 있다. 어쨌든 고언어 진영에서도 새 버전마다 GC 성능 향상은 항상 언급된다. 맨날 몇% 빨라진다고 하는데 도대체 원래 얼마나 느렸길래...
# 공식 패키지 매니저의 부재
요즘 언어들에서 제일 중요한게 패키지 매니저인데, 만든분들이 C스타일이라서 그런지 공식 패키지 매니저가 아직까지도 없다. dep이라고 공식툴 후보가 있긴 한데 아직은 공식툴이 아니다. 1.11정도면 공식 툴이 될것 같으나 그때까지의 혼란함은 유지될것 같다. 물론 훌륭한 패키지 매니저 툴들이 존재하지만 모두 비공식이고 노드 진영의 npm처럼 독과점인 것도 아니기 때문에 사용자들의 혼란함은 피할 수 없다. npm도 요즘 yarn 때문에 많이 흔들리긴 하다만. 아무튼, 공식 패키지 매니저가 확립되는 순간 고언어의 인기는 더더욱 치솟으리라 예상해본다.
# 고언어2의 불안함
벌써 고언어도 버전이 1.9다. 포럼에서는 1.9 다음은 2.0 아니냐고 묻는 사람도 있고 ㅎㅎ. 2.0이 언젠간 나오겠지만 지금은 아니다. 다음 버전은 1.10이고 호환성은 유지된다. 2.0이라는 의미는 하위 호환성이 깨진다는 의미이기도 하고, 간결했던 언어가 치덕치덕 장황해질까봐 걱정하는 이들이 많다. 아마도 파이썬3의 트라우마 때문이겠지. 고언어도 완벽한 언어는 아니고 애매하거나 언어적으로 개선이 필요한 부분들이 논의되고 있고, 이 때문에 고언어2.0에서 어떤 형태로 변화할 것인지에 대한 기대감과 두려움이 공존하는 것 같다. 고언어가 여러 통계에서 인기순위가 10위권 내외라고 하는데, 2.0의 결과물에 따라 더 상승할지 하락할지도 결정될 것 같다. 생각해보니 비슷한 예가 파이썬2/3 뿐만 아니라 앵귤러JS/앵귤러2도 있다. 통계 나올때 이들은 항상 다른 언어로 구분된다. 고언어도 통계에 고1/고2로 나눠져서 나오게 된다면...
# 총평
두서없이 나열해보았지만, 확실히 개성이 있는 언어이고 단점은 평이하고 장점이 뚜렷하다. 나도 앞으로 필요에 따라 망설임없이 선택하여 사용할 것이고 남들에게 추천도 할 것이다. 마스코트 고퍼도 굉장히 귀엽다. 인형을 구하고 싶었는데 컨퍼런스에나 가야 구할 수 있는것 같더라. ㅠㅠ 활용하면 좋을 분야는
추상적으로 보자면
- 로직이 복잡하여 순차적으로 처리해야하고 고성능이 필요할 때
- 수천개 이상의 논리적 흐름(스레드)이 필요할 때
- C/자바보다 코딩은 편하고, 자바보다 좀 더 나은 성능을 원할 때
- 프레임워크 없이 언어만 배워서 개발하고 싶을 때
구체적으로 보자면
- 백엔드 서버
- 동시접속이 많은 소켓 서버
- 배치 처리
GUI, 웹, 모바일 안되는건 없지만 굳이 해당 분야에서는 더 생산성 좋은 방법들이 많으니, 해당 분야에 추천할만한 정도는 아니겠다.