Express 작성자 TJ는 Node.js에 작별을 고하고 Go_node.js로 향합니다.

우선 TJ의 Farewell Node.js를 번역한 글입니다. 이 글을 읽고 정말 충격을 받았지만, 글쓴이의 견해 중 일부에는 동의하지 않습니다. 예를 들어 Node.js의 패키지는 다음과 같습니다. Register는 많은 장점 중 하나이지만 Go는 이 측면이 약간 부족합니다. 제 개인적인 한계로 인해 번역할 때 이해가 안 되는 부분이 많았습니다. 저도 작가님 블로그와 스택오버플로에 가서 몇 가지 질문을 하고 답변을 얻었습니다. 번역에는 아직 불완전한 부분이 많이 있는데, 조언을 얻으셨으면 좋겠습니다.

PS. Node.js 초보자로서 TJ의 노고에 감사드리며 좋은 여행 되세요.

텍스트:

Node.js는 안녕

Node.js 영역 나가기

저는 오랫동안 프로덕션 환경에서 Node.js와 싸워왔고, 안타깝게도 더 이상 이 일을 하는 것이 즐겁지 않기 때문에 적어도 지금은 이것이 공식적인 작별 인사입니다. 더 중요한 것은 관리자가 필요하다는 것입니다.

Node는 어떤 면에서는 훌륭하지만 요즘 제가 관심을 갖고 있는 소프트웨어 유형에는 적합한 도구가 아닙니다. 나는 여전히 웹사이트에 Node를 사용할 계획이지만, 프로젝트 유지에 관심이 있다면 Github 사용자 이름, npm 사용자 이름, 프로젝트 이름을 댓글로 남겨 알려주세요. 일반적으로 내가 요청하는 것은 기존 API를 완전히 변경하지 않는다는 것입니다. 정말로 이 작업을 수행하려면 새 프로젝트를 시작하는 것이 좋습니다.

Koa는 제가 계속해서 유지하고 있는 프로젝트입니다. (Co와 친구들과 함께)

성배 이야기

나는 항상 C를 좋아했지만 C 개발 분야에 종사하는 모든 사람들은 C가 가치는 있지만 오류가 발생하기 쉽다는 것을 알고 있습니다. 일상적인 작업에서 언어 선택을 정당화하는 것은 어렵습니다. 왜냐하면 언어가 작업에 가장 빠른 것은 아니기 때문입니다. 단순함은 항상 칭찬받는 이유이기도 하지만, 수많은 템플릿 없이는 멀리 갈 수 없습니다.

분산 시스템 개발에 더 많이 참여할수록 가용성과 견고성보다 노드 성능이 더 높은 경향이 점점 더 좌절감을 느끼게 됩니다. 지난 주에 저는 상대적으로 큰 규모의 분산 시스템을 Go로 다시 작성하여 더욱 강력하고 성능이 뛰어나며 유지 관리하기 쉽게 만들었습니다. 동기 코드는 일반적으로 더 우아하고 개발하기 쉽기 때문에 테스트 가능한 적용 범위가 더 넓습니다.

Go가 성배라고 말하는 것은 아닙니다. 완벽하지는 않지만 오늘날 존재하는 많은 언어에 있어서 Go는 나에게 훌륭한 대답입니다. Rust 및 Julia와 같은 "차세대" 언어가 더 많이 틈새시장을 찾고 성숙해짐에 따라 우리는 더 훌륭한 솔루션을 갖게 될 것이라고 확신합니다.

개인적으로 GO 언어의 반복 속도 때문에 매우 기대가 되었어요. 그들이 버전 2.0에 도달하기를 열망하는 모습을 보고 매우 기뻤고, 제가 들은 소식에 따르면 그들은 두려워하지 않고 원래의 위대한 것들을 깨뜨렸습니다. 그것이 사실이라면 나는 그것을 좋아할 것입니다. 왜냐하면 그것이 언어에 정말로 좋다면 기존의 것을 빨리 깨뜨려야 한다고 믿기 때문입니다. 그러나 나는 또한 많은 시스템을 운영하는 소프트웨어 거물도 아닙니다. :디

편집자: 메일링 리스트에 제출된 일부 내용을 잘못 해석한 것 같습니다. 그들은 언제든지 획기적인 변경을 하려고 하지 않았습니다. @enneff

가야할 이유

Node가 귀하에게 적합하고 걱정할 것이 없다면 Node는 여전히 훌륭한 도구입니다. 하지만 뭔가 마음에 걸리는 것이 있다면 상자 밖으로 나가서 상자 밖에 무엇이 있는지 확인하는 것을 잊지 마세요. Go로 제품을 만든 지 처음 몇 시간 만에 저는 이미 매료되었습니다.

다시 말하지만 Go가 절대적으로 최고의 언어이므로 사용해야 한다는 뜻은 아닙니다. 하지만 나이에 비해 굉장히 성숙하고 강인해요. (대략 Node와 같은 나이였을 때). 유형 리팩토링은 재미 있고 간단하며 Go에서 제공하는 작업 및 디버깅 도구는 훌륭하며 커뮤니티는 문서, 형식, 벤치마크 및 API 디자인에 대해 매우 강력한 규정을 가지고 있습니다.

Node의 극단적인 모듈성에 너무 익숙해서 Ruby의 썩은 표준 라이브러리를 경험했기 때문에 처음 Go에 대해 들었을 때 Go의 표준 라이브러리가 끔찍하다고 생각했습니다. 이 언어에 대해 더 깊이 알게 된 후에 압축, json, IO, 버퍼링된 IO, 문자열 작업 등과 같은 이 단계의 대부분의 표준 라이브러리가 매우 필요하다는 것을 깨달았습니다. 이러한 APIS의 대부분은 잘 정의되어 있고 강력합니다. 이러한 표준 라이브러리를 사용하면 전체 프로그램을 쉽게 작성할 수 있습니다.

타사 Go 패키지

대부분의 Go 라이브러리는 비슷해 보이며 지금까지 사용한 대부분의 타사 코드는 고품질입니다. 이는 JavaScript가 범위 내에서 다양한 기술 수준의 개발자를 끌어들이기 때문에 Node에서 찾기 어렵습니다.

Go 패키지의 경우 등록 센터가 없으므로 일반적으로 동일한 패키지가 5~6개 동시에 표시됩니다. 이로 인해 때때로 혼란이 발생할 수 있지만 각 패키지를 주의 깊게 검토하여 어떤 패키지가 가장 좋은 솔루션인지 결정해야 한다는 흥미로운 부작용이 있습니다. Node에는 일반적으로 "redis", "mongodb-native" 또는 "zeromq"와 같은 표준 패키지가 있으므로 여기서 멈추고 해당 패키지가 가장 좋은 패키지라고 추론합니다.

분산 작업을 수행하는 경우 Go의 인상적인 동시성 기반 데이터 유형이 매우 유용하다는 것을 알게 될 것입니다. Node의 생성기로 비슷한 것을 달성할 수 있지만 제 생각에는 생성기가 작업의 절반에 불과합니다. 독립적인 오류 처리가 없으면 보고 스택은 여전히 ​​평범합니다. 이러한 솔루션이 잘 작동하면 커뮤니티가 재편될 때까지 3년을 기다리고 싶지 않습니다.

제 생각에는 Go의 오류 처리 능력이 뛰어납니다. Node는 모든 오류를 고려하고 무엇을 해야 할지 결정해야 한다는 점에서 훌륭합니다. 그러나 Node는 다음에서 실패합니다.

콜백을 반복적으로 수행할 수 있습니다

콜백을 전혀 하지 않고 불안정한 상태에서 길을 잃을 수 있습니다. (예를 들어 오류 처리 콜백을 전달하는 것을 잊은 경우 오류가 발생하면 노드는 피드백 없이 오류를 무시합니다.)

초기 오류가 발생할 수 있습니다

이미터는 잘못된 이벤트를 여러 개 받을 수 있습니다

잘못된 이벤트 처리를 잊어버리면 모든 것이 망가집니다

무엇을 잘못 수행해야 할지 확신할 수 없는 경우가 많습니다

오류 처리가 매우 중복됩니다

콜백이 형편없습니다
Go에서는 내 코드가 끝나면 코드가 종료되고 문 내에서 다시 실행할 수 없습니다. 노드에서는 이것이 정의되지 않습니다. 라이브러리가 실수로 콜백을 여러 번 호출하거나 핸들러를 제대로 지우지 못해 코드가 다시 실행될 때까지 프로그램이 완전히 실행되었다고 생각할 수 있습니다. 실제 생산 코드에서 이러한 이유를 찾는 것은 매우 어려운데 왜 굳이 귀찮게 할까요? 다른 언어에서는 이러한 고통을 겪지 않습니다.

미래의 노드

그래도 Node가 잘되서 많은 사람들이 막대한 투자를 했으면 좋겠습니다. 그런 잠재력이 있거든요. 저는 Joyent와 팀이 유용성에 초점을 맞춰야 한다고 생각합니다. 애플리케이션이 취약하고 디버깅, 리팩터링 및 개발이 어렵다면 성능은 의미가 없습니다.

4~5년 후에도 여전히 이 모호한 오류 "Error: getaddrinfo EADDRINFO"가 발생한다는 사실은 Node의 개발 우선순위가 어디에 있는지 알려줍니다. 당연히 시스템의 핵심을 구축하는 데 집중할 때 이러한 사항을 놓치기 쉽습니다. 내 생각엔 사용자들이 이런 종류의 것에 대해 어떤 결과도 보지 못한 채 몇 번이고 의견을 표명해왔던 것 같아요. 우리는 일반적으로 우리가 가지고 있는 것이 이미 완벽하다는 주장에 대해 소수의 응답을 받습니다. 실제로는 그렇지 않습니다.

스트림이 중단되고, 콜백이 사용하기 쉽지 않고, 오류가 불분명하며, 도구 사용이 쉽지 않습니다. 커뮤니티 규정이 있지만 Go에 비해 부족합니다. 그럼에도 불구하고 웹 페이지 생성이나 분산된 API 또는 프로토타입과 같은 일부 특정 작업에 Node를 계속 사용할 수 있습니다. Node가 근본적인 문제 중 일부를 해결할 수 있다면 관련성을 유지할 가능성이 있지만 더 높은 성능과 더 높은 가용성이라는 대안이 있는 경우 가용성보다 성능에 대한 논쟁은 그리 멀리 가지 않습니다.

Node 커뮤니티가 제너레이터를 Node의 핵심 부분에 수용하고 구현하여 오류를 적절하게 전파하기로 결정했다면 이를 참고할 가능성이 있습니다. 이를 통해 Node의 가용성과 견고성이 대폭 향상됩니다.

좋은 소식은 얼마 전 StrongLoop의 핵심 코드를 제공하는 훌륭하고 재능 있는 사람들과 이야기를 나눴다는 것입니다. 그들은 플랫폼에 대한 개발자의 반응을 듣고 명확한 접근 방식을 취하고 있으며 향후 Node를 더 쉽게 사용할 수 있도록 이러한 문제를 해결하는 올바른 방법을 찾을 계획입니다. 여러 회사가 핵심 부품을 동시 개발하는 갈등이 어떻게 끝날지는 모르겠지만, 개발자 중심의 쪽이 승리했으면 좋겠습니다.

인신공격하려는 의도는 아닙니다. Node와 함께 일하거나 Node에서 일하는 정말 재능 있는 사람들이 많이 있지만 저는 더 이상 거기에 관심이 없습니다. 저는 Node 커뮤니티에서 즐거운 시간을 보냈고 정말 흥미로운 사람들을 만났습니다.

이야기의 교훈은 자신이 속한 집단에 국한되지 말라는 것입니다! 다른 곳에서 무엇이 사용 가능한지 확인하고 다시 프로그래밍을 즐겨보세요. 세상에는 훌륭한 솔루션이 너무 많아서, 그 솔루션을 사용하기에는 너무 오래 기다리는 실수를 저질렀습니다!