왜? 타입스크립트 네이티브 컴파일러에 Go를 선택했나?
언어 선택은 언제나 뜨거운 주제입니다! 우리는 최근뿐만 아니라 이전 조사에서도 여러 언어 옵션을 광범위하게 평가했습니다. 일부 컴포넌트를 네이티브 언어로 작성하면서도 핵심 타입 체크 알고리즘은 JavaScript에 유지하는 하이브리드 접근 방식도 고려했습니다. 또한, 다양한 데이터 표현을 실험하는 여러 프로토타입을 작성하고, 기존의 네이티브 TypeScript 파서를 사용하는 swc, oxc, esbuild 등의 접근 방식을 깊이 조사했습니다.
결론적으로, 여러 언어가 처음부터 다시 작성하는 상황에서는 적합할 수 있지만, 우리의 상황에서는 다양한 기준을 고려했을 때 Go가 가장 적합했습니다.
가장 중요한 이유는 기존 코드베이스와의 호환성을 유지하는 것입니다. 우리는 새로운 코드와 기존 JavaScript 코드베이스를 한동안 함께 유지할 계획이며, 구조적으로 유사한 코드베이스를 유지할 수 있는 언어가 중요했습니다. Go는 TypeScript 코드베이스의 기존 패턴과 유사하여 포팅이 용이합니다.
또한, Go는 메모리 레이아웃 및 할당을 세밀하게 제어할 수 있으면서도, 코드 전체에서 수동으로 메모리를 관리할 필요가 없습니다. Go의 가비지 컬렉터(GC) 단점은 우리의 코드베이스에서 큰 문제가 되지 않습니다. 일괄 컴파일(batch compilation)에서는 프로세스가 종료되므로 GC가 필요 없고, 비일괄(batch가 아닌) 상황에서도 대부분의 메모리 할당이 프로그램 전체 수명 동안 유지되므로 GC 실행 시점을 효과적으로 조정할 수 있습니다.
또한, Go는 트리 구조를 위아래로 탐색하는 그래프 처리 작업이 많을 때, 특히 다형성을 활용하는 경우 매우 편리한 기능을 제공합니다.
한편, Go의 JavaScript와의 상호 운용성(interop)은 다른 대안들보다 부족하지만, 이를 해결하기 위한 계획이 있으며, 향후 더 효율적인 JS API를 제공할 예정입니다. 기존 API 모델이 소비자가 내부 구조를 직접 수정할 수 있도록 허용하여 최적화를 방해하는 요소가 있었지만, 새로운 코드베이스에서는 이를 개선할 수 있는 여지가 큽니다.
개인의견:
Go 언어는 구글에서 2009년 11월 경에 최초 출시 발표했고 Typescript 는 2012년 10월 이네요.
너무 오래되어 잘 기억은 나지 않지만 원문에서 언급하듯이 코드베이스 유지에 중요하다고 하고 있어서
출시 당시 시대적 영향으로 후에 출시된 Typescript 에서 Go 언어에 대한 코드 베이스에 영감을 많이 받지 않았을까 하는 추측을 해봅니다.
혹시나 하여 GPT 한테도 물어봤습니다.
Q: 프로그래밍인 언어적인 영향이 아닌 시대적 영향은 없었어?
GPT왈: TypeScript와 Go는 언어적으로 직접적인 연관성은 없지만, 대규모 소프트웨어 개발, 생산성 향상, 멀티코어 및 병렬 처리 트렌드라는 시대적 요구 속에서 각각의 역할을 하며 등장했습니다. TypeScript는 JavaScript 개발을, Go는 서버 개발을 최적화하기 위해 탄생했지만, 둘 다 **"현대적인 소프트웨어 개발을 더 쉽고 안정적으로 만들자"**는 공통된 시대적 흐름 속에서 발전한 언어들입니다.