그런데 GitHub 토론에서 왜 Go를 채택했는지에 대해서 설명했는데 댓글들을 보면은 “왜 C#이나 Rust를 채택하지 않았냐.”, “마이크로소프트는 자기들의 제품을 써보지도 않는다(원문은 dogfood).”, 심지어는 “닷넷을 포기해야 한다. 마이크로소프트 내부에서 조차 잘 쓰지 않는다.”, “C#과 닷넷을 이렇게까지 천대(?)한다면 C# 커뮤니티는 결국 사라질 것이다.”(물론 이 두개는 중요한 반박이 있긴 했습니다.), “C# 컴파일러를 Go로 다시 작성하기를 기대한다.”(물론 이건 농담이었을겁니다.) 이런 반응이 있는 반면 “이해할만한 결정이다.”, “MS가 닷넷을 천대한다? 이미 MS의 인프라 전반에서 쓰이고 있다. 말도 안돼는 주장이다.”, “Rust는 복잡하기에 이런 프로젝트에 적합하지 않다.” 이런 반응도 있더군요. 논쟁이 격해지다보니 결국은 하루만에 스레드를 잠갔습니다.
Go의 핵심 기능은 goroutines라고 알고 있는데 이것 때문에 CPU 집약적인 작업이라 할 수 있는 컴파일에 적합한 언어라고 생각하지 않았나 싶습니다.
이 사건이 더욱 충격적이었던 이유는 단순히 타입스크립트의 컴파일러를 자사의 언어인 C#이 아닌 Go로 포팅하기로 결정했기 때문만은 아닙니다. 타입스크립트를 만든 인물이 바로 앤더스 하일스베르그인데, 그는 C# 또한 설계한 인물입니다. 즉, 자신이 직접 만든 언어인 C# 대신 다른 언어를 선택했다는 점에서 많은 이들이 "C#은 이제 물 건너갔다"라는 감정적 반응을 보이게 된 것이죠.
하지만 이는 다음의 기술적 판단 때문이라고 합니다.
기존 JavaScript/TypeScript 기반 구조를 가장 손쉽게 포팅할 수 있는 언어를 선택했다고 합니다. Rust나 C#는 구조적 차이가 크고, Rust는 GC가 없어 호환성이 낮고, C#은 플랫폼 및 AOT 면에서 Go에 비해 제약이 있었다고 합니다.
하지만 기술적 판단에 의해 C#이 아닌 Go가 선택되었다는 점은 납득은 되나 개인적으로는 참 아쉬운 결정 같습니다. Native AOT가 아직 Go 수준에 도달하지 않았다고 판단되었다는 점, 메모리 사용량 및 GC 사용 측면에서 컴파일러가 가져야 하는 메모리 효율성 및 GC 지연이 낮은 Go에 비해 상대적으로 떨어졌다고 판단되었다는 점이 아쉽습니다.
다른 한편으로, 프론트엔드 스택이 다른 프로그래밍 언어에 대한 관심을 가질 만큼 여유가 생겼기 때문에 Blazor WebAssembly도 프론트엔드 개발자들과 함께 나란히 이야기할 수 있게 되어서, 타입스크립트 컴파일러 기술로 닷넷이 채택되지 않았다는 점이 아쉬운 것과는 별개로 이야기해볼 수 있는 여지가 있지 않는가 생각했습니다.
사용자 층이 많은 에코시스템에 닷넷이 더 빠르고 넓게 진출할 수 있는 여지는 항상 열려있지 않는가 생각합니다.
Engineer 3 - Last weekend I thought I’d try learning Go. While I was going through the tutorials, I realized how similar the language was to TypeScript. It’s almost as if you could just swap the positions of the types and add a few asterisks and they would be the same! So, I hacked a little text transformer together and tried converting the TS codebase. It looks like it’s about 80% correct!
Director/VP - I have no idea what the first two engineers just said. But I’m hearing Engineer 3 say that he already ported the thing last weekend. So, we’re using Go. Ship it.
"재설계"라는 단어 보다는 “포팅” 이라는 단어를 선택한 것은, 거의 텍스트 변환 수준의 작업이었기 때문일 것이라 생각합니다.
실제로 기존 자바 스크립트 코드와 포팅된 Go 코드의 외형이 거의 일치하더군요.
C# 으로 포팅할 때는 static class 라는 보일러 코드가 필수적으로 수반되어야 합니다. 이는 일급 멤버로서 함수를 지원하는 많은 언어는 네임스페이스의 멤버로 함수를 선언할 수 있지만, C# 은 그렇지 않기 때문입니다.
C# 을 그렇게 변경하는 것은 F# 에 대한 위협일 수도 있고, 함수형 언어들이 가진 설탕 문법도 아직은 충분하지 않아, 포팅 작업의 효율성을 떨어뜨리는 원인이었을 것입니다.
참고로, FP 스타일을 채택하면, OOP 스타일 보다 보일러 코드가 매우 줄어듭니다.
이 것을 잘 보여 주는 게 asp net core minimal api 와 컨트롤러를 사용하는 wep api 코드 입니다.
미니멀 api 는 작은 프로젝트에나 적당하다고 말하는 부류들이 있는데, 미니멀 api 와 유사한 스타일을 가진 nodejs 를 사용하는 거대 사이트가 많다는 사실을 모르고 하는 말인 것 같습니다.
읽을 거리 - 닷넷데브